@mbncp01 Python itself is very fast. But you can make it slow as hell by nesting functions, using dictionaries or starting function overriding hell to make coding more convenient and "intelligent" but slowing down execution dramatically.
On iOS, I have only tried Pythonista and it works quite well. It's a huge bummer that it has no on-board access to coremidi and only basic access to coreaudio (simple recording and playback on default audio device works).
The only workaround is to use its UDP stack to send and receive OSC packets that are translated somewhere else.
Well, Streambyter can talk UDP too so that could be a fun experiment if latency isn't too critical.
Actually it would be worth a try communicating over 127.0.0.1 = localhost.
Scripting audio plugins. Hell yeah. Join the party @giku 😇
Edit: Sorry, Streambyter can only send UDP packets.
But there's another option: Apple Network MIDI over UDP and Bonjour.
@mbncp01 Of course it would need to work inside the AUv3 but using Pythonista would help to test performance without building a new app, that's why I mentioned it.
About Mozaic speed: I don't remember exactly but last year, I wanted to build a MIDI clock processor with the help of an experienced AB forum member and had to stop at some point because of the limited performance.
Most likely you won't hit these limits with "normal" message processing as long as they're not too time critical.
The guy who invented midi clock is in jail now, if it makes you feel better :)
I already did some test: Mozaic vs StreamByter(MidiFire) vs JavaScript, and didn't see any difference. Well, all? host will quantize midi to the audio buffer.
Will test Mozaic vs Atom JS in a "zero" latency situation, with a nasty for loop. Let you know.
Haha, you wouldn't believe it, I've been fighting for good MIDI clock support in iOS apps for ages 😅
The thing is: Love it or hate it, lots of MIDI hardware rely on MIDI clock as the only available sync mechanism and today, we have fairly good MIDI clock support in quite a number of iOS apps.
I believe you, about 3 years ago I sold all my gear, since then I sleep better, but I do have some regrets(virus ti2 polar, little phatty ;)
Edit: I knew something was wrong, well the Mozaic instance process with zero latency was set to NO , do we have a 50 msec latency in MidiFire, when zero latency is set to no ? This is huge !!
So all 3 are within the same msec, using a 10000 for.. loop with both plugs, Mozaic was kind of crashing with the 20000 loops
Comments
@mbncp01 Python itself is very fast. But you can make it slow as hell by nesting functions, using dictionaries or starting function overriding hell to make coding more convenient and "intelligent" but slowing down execution dramatically.
On iOS, I have only tried Pythonista and it works quite well. It's a huge bummer that it has no on-board access to coremidi and only basic access to coreaudio (simple recording and playback on default audio device works).
The only workaround is to use its UDP stack to send and receive OSC packets that are translated somewhere else.
Well, Streambyter can talk UDP too so that could be a fun experiment if latency isn't too critical.
Actually it would be worth a try communicating over 127.0.0.1 = localhost.
Scripting audio plugins. Hell yeah. Join the party @giku 😇
Edit: Sorry, Streambyter can only send UDP packets.
But there's another option: Apple Network MIDI over UDP and Bonjour.
@rs2000
Well that's not really the way to go. The scripting engine needs to be embedded in the auv plug.
Atom js is an "extension" of Atom, and not just a script that runs in the wild.
The callbacks(midi in,..) are directly generated by atom and probably run by a thread created by the caller.
Not sure how it works on iOS (I really need to get a new macbook air), but all auv functions can(could) be implemented into the script.
Currently, in Atom, we miss a few host related function (start,stop, tempo,..) but again his intention wasn't to create a midi plug
>>Scripting audio plugins. Hell yeah. Join the party
I can send you some ear plugs
@mbncp01 Of course it would need to work inside the AUv3 but using Pythonista would help to test performance without building a new app, that's why I mentioned it.
I wonder what these ear plugs would look like 😉
Hygienic, cheap and almost comfortable -32 db !!
Great when you want your neighbors to enjoy your music without being yourself uncomfortable 🥵
more seriously, is there a python engine that could run within a plug-in ?
Actually I find Mozaic pretty fast, any code to submit ?
😅
No, none that I know of. Good idea though.
About Mozaic speed: I don't remember exactly but last year, I wanted to build a MIDI clock processor with the help of an experienced AB forum member and had to stop at some point because of the limited performance.
Most likely you won't hit these limits with "normal" message processing as long as they're not too time critical.
@rs2000
The guy who invented midi clock is in jail now, if it makes you feel better :)
I already did some test: Mozaic vs StreamByter(MidiFire) vs JavaScript, and didn't see any difference. Well, all? host will quantize midi to the audio buffer.
Will test Mozaic vs Atom JS in a "zero" latency situation, with a nasty for loop. Let you know.
Haha, you wouldn't believe it, I've been fighting for good MIDI clock support in iOS apps for ages 😅
The thing is: Love it or hate it, lots of MIDI hardware rely on MIDI clock as the only available sync mechanism and today, we have fairly good MIDI clock support in quite a number of iOS apps.
@rs2000
I believe you, about 3 years ago I sold all my gear, since then I sleep better, but I do have some regrets(virus ti2 polar, little phatty ;)
Edit: I knew something was wrong, well the Mozaic instance process with zero latency was set to NO , do we have a 50 msec latency in MidiFire, when zero latency is set to no ? This is huge !!
So all 3 are within the same msec, using a 10000 for.. loop with both plugs, Mozaic was kind of crashing with the 20000 loops
Take all this with a grain of salt..
Well finally did an in function test, using Date.now() for Atom's JS and SystemTime for Mozaic, a 50'000 for .. loop with a simple test showed:
1 msec with JS (6 msec with 500'000) and about 30 msec with Mozaic(standalone).
So Atom's JS is about 50 times faster (in this case). iPad Air 4, but again with a grain of salt, this should be tested from a host.
The functions, if you want to try on your new iPad Pro with the M1 chip:
JS: ( use a higher value for a better accuracy )
const tm = Date.now();
for(var i = 0; i < 50000; i++) {
if (i < 0) return;
}
console.log(Date.now()-tm);
Mozaic:
tm = SystemTime
For n = 0 to 50000
if n < 0
exit
endif
endfor
log SystemTime - tm