Recompile all patches

[pingdynasty]

It would be good to have a way (an admin function) to recompile all patches, e.g. when the compiler has been updated.

If compilation fails, it shouldn't overwrite an existing sysex from a previous compilation (I think this is how manual compilation currently works, which is good).

Also nice to have:

• list of compilations that failed/succeeded (after compile all)
• date stamp on the sysex files so you can see when it was compiled

[sam-artuso]

I had already built a quick command line script that will compile all patches in one go.

There's a problem I need to find a workaround to though. Each patch compilation will download the source files from GitHub. The files are downloaded making API calls to the GitHub API. However the API is rate-limited and it allows only 60 calls per hour for non-authenticated calls, which is not sufficient for dowloading all the sources. As a result, the compilation will start to fails after the some dozens of patches have compiled.

The solution is to switch to authenticated calls. This is not straightforward because authenticated calls must be made server-side for security reasons (at the moment we're using only client-side calls made with JavaScript on the users' browsers). I'll take a look later on.

[pingdynasty]

Authenticated calls sounds like a lot of work for little payback. We could otherwise consider caching source files, and only update if the revision has changed.

Regardless, this is not high priority, lots of other things to do first: online compiler, patch test (web audio), patch upload (web midi), compilation page with text editor/file upload.

Meanwhile, could the command line script be easily updated to pause for 1 minute between calls? It would still be very useful if it takes > 1hr to run.

I had already built a quick command line script that will compile all patches in one go.

There's a problem I need to find a workaround to though. Each patch compilation will download the source files from GitHub. The files are downloaded making API calls to the GitHub API. However the API is rate-limited and it allows only 60 calls per hour for non-authenticated calls, which is not sufficient for dowloading all the sources. As a result, the compilation will start to fails after the some dozens of patches have compiled.

The solution is to switch to authenticated calls. This is not straightforward because authenticated calls must be made server-side for security reasons (at the moment we're using only client-side calls made with JavaScript on the users' browsers). I'll take a look later on.

---

Reply to this email directly or view it on GitHub: https://github.com/pingdynasty/OwlServer/issues/81#issuecomment-125237036

[sam-artuso]

Meanwhile, could the command line script be easily updated to pause for 1 minute between calls? It would still be very useful if it takes > 1hr to run.

Good idea! By making 1 API call every minute we can never run out of API calls. Unfortunately to GitHub it doesn't make any difference if the calls come from the script that builds all patches or from the live website. So, if you ran the 'build all' script, there wouldn't be any API calls left for the users of the website.

We could make an API call every 2 minutes instead, and that would leave 30 API calls left to the end user, which compared to the current traffic of the website sounds reasonable.

End users trigger one API call for each source file every time they open a single patch. Obvs, there's also one API call for each source file when a a patch is compiled.

[pingdynasty]

great, make it so

Martin

Meanwhile, could the command line script be easily updated to pause for 1 minute between calls? It would still be very useful if it takes > 1hr to run.

Good idea! By making 1 API call every minute we can never run out of API calls. Unfortunately to GitHub it doesn't make any difference if the calls comes from the script that builds all patches or from the live website. So, if you ran the 'build all' script, there wouldn't be any API calls left for the users of the website.

We could make an API call every 2 minutes instead, and that would leave 30 API calls left to the end user, which compared to the current traffic of the website sounds reasonable.

End users trigger one API call for each source file every time they open a single patch. Obvs, there's also one API call for each source file when a a patch is compiled.

---

Reply to this email directly or view it on GitHub: https://github.com/pingdynasty/OwlServer/issues/81#issuecomment-125409009

[sam-artuso]

On staging and live too. Most patches still not compiling because of #80.

[sam-artuso]

I just finished to build all patches on the live server.

FYi, here's a full list of patches that failed to build:

Guitarix/Distortion1 Qompression Guitarix/OscTube Karplus Strong Guitarix/BigMuffFuzz OL/DualFreqShifter OL/DualPitchShifter OL/ThruZeroFlanger OL/WeirdPhaser OL/Blipper Contest/blo bleep Guitarix/Overdrive State Variable Filter Resonant Low Pass Filter Leaky Integrator Vibro-Flange MDA/Stereo Psyche Filter OL/DroneBox Guitarix/Compressor Guitarix/Tone Guitarix/PhaserMono Guitarix/Moog Filter OL/StereoFreqShifter Stereo Delay Arp-Scale Wavetable

[pingdynasty]

fixed the C++ patches that failed, remaining ones are Faust or PD.

[sam-artuso]

This is a complete list of patches that won't compile in the live environment.

Name	Type
Guitarix/Distortion1	Faust
Guitarix/OscTube	Faust
Karplus Strong	C++
Guitarix/BigMuffFuzz	Faust
OL/DualPitchShifter	C++
OL/WeirdPhaser	C++
OL/Blipper	C++
Guitarix/Overdrive	Faust
OL/DroneBox	C++
Guitarix/Compressor	Faust
Guitarix/Tone	Faust
Guitarix/PhaserMono	Faust
Guitarix/Moog Filter	Faust
OL/StereoFreqShifter	C++
HeavyOWL	PureData
Super Saw Oscillator	C++
Arp-Scale	PureData
Wavetable	PureData

Setting aside the PureData patches for now, for which we're looking for a solution, we have:

• 7 C++ patches; and
• 8 Faust patches.

Since we have a total of 25 Faust patches (most of which do compile successfully), I think it shouldn't be a problem with my build script.