@mbncp01 Are you running StreamByter in MIDIFire or as AUv3? I've only used it as AUv3, or stand-alone. I'll try it in MIDIFire and see if it performs differently.
Good. I just tried it in MIDIFire and it does not work. The MIDIFire version cannot access the filesystem, so the Set include does not work.
It should work fine in AUM, provided you've stored the include file in StreanByter's iCloud with the correct name. In fact, when I load either the send or receive scripts, the numbers appear immediately, even before Install Rules. I assume you're loading the script using the hamburger menu in the lower right of the SB window. Does it display "iCloud is available" when you do that? If you're just seeing "--" where the numbers should be, you need to Install Rules to compile the program. That's when the initialization is executed.
If it still doesn't work, you could zip the files and post them here, so I can test with your exact code.
OK. I may have confused you by adding the ".txt" extension. I only did that so you could load the file into a text editor, prior to copying the text to SB. When you invoke the SB save command, you must not use any extension. So, the steps are:
Open CC_note_map_include.txt in a text editor/viewer.
Select All and Copy
Switch to SB
Hamburger menu, select Factory, Default, Load (erases the edit area).
Paste
Install Rules to check the code
Hamburger menu, select iCloud, Save
Enter "CC_note_map_include" in name field (replace "New preset") and Save, Done.
Repeat for the script
Install Rules.
And, I just tried your file. After you paste the include text, you can compile it using Install Rules, even though it's not a complete program. The End after Set LB1 I1 is missing the "E", so it errors out. So that may be the problem.
Edit: used your copy of the include, corrected, with the send script, and looks OK.
The missing E is just a typo, once I pasted in textedit I saw that I still had my Set LB0|1, and when cleaning I removed that E.
I just tried with Drambo and AB3, same result, both LB show zero.
If I have at the end of the include Init maps sub
Sub init.._maps
#bypassing the 2 calls
Ass L1 = 55
Set LB0 L1
End
it shows 0
There is a bug somewhere, which iPadOS are you using, myself I'm on 14.4.2 , Air4
Now I just tried to create a simple include file and a simple std script, just stating some var, and this works fine, in my main script I get the var correctly ... weird
That's annoying. I'm on iPadOS 14.4.2, iPad 6. StreamByter version 1.7, shown in the iPad Storage listing; doc in the app says 1.6. I don't think the Labels should ever show zero; they normally show "--" when not set. When you feel like it, post the script and the include file that don't work. As I said, your include file worked fine after I fixed the typo, so there must be a problem in the script.
I think the problem is in corrupted files. I changed the include file (only 2 CC) and stored it again on the "local" cloud.
Now it still shows me 17 3, which means it is still using the previous file, so there is really something fishy about the app itself.
Sorry, but I don't feel to spend anymore time on this. Mozaic works well in MidiFire with zero latency. I guess using streambyter is a bit more efficient, but from my tests, I didn't see any difference using either Mozaic or Streambyter( the midi timestamp within a host is always equal), and as I can code in Mozaic script without having to think about how I should code, streambyter is not really a priority.
IMO, the real interest would be if a streambyter script(used in MidiFire) could send to a specific midi port. From what I see it's only for UDP communication, which I don't use.
This reminds me Bidule where a filter module would have 2 outlets, one for the filtered events, one for the other, or 16 outlets, one for each channel, was great, though it wasn't perfect either. Now I'm not blaming any devs, creating a new app can be fun, but continuous FR, iOS changes, .. is a nightmare on the long run, unless to take the right medication :)
Did you change the "set inc icloud" in the script to "set inc local"?
No need to be sorry. You set the challenge, I answered it with a modular solution where one configuration can control both sender and receiver. I'm sure you'll enjoy working with Mozaic.
StreamByter in MIDIFire can send to any MIDI port, including the virtual ports configured by the app. You just set the wiring the way you want. You can send MIDI on different channels, then use two channel filters to route different channels to different ports. The UDP feature is an obscure optional feature, and its "port" parameter is a UDP port on another computer, nothing at all to do with iOS MIDI ports.
If you didn't change the using script to use the local copy of the include, it will still use the iCloud one.
You mentioned StreamByter used in MIDIFire. In the first configuration I posted, the StreamByter script could send messages on different MIDI channels. The two Channel Strips filter them to different MIDI ports, and can change the MIDI channel back to channel 1. This allows StreamByter to direct messages to different MIDI ports. So that meets your requirement, using the normal components of MIDIFire.
I’m not a big fan of using midi channel on this type of op, as they already have a meaning, but I can embed one or more standard midi messsages in a sysex and the first byte would be the port to send to(blocking others).
>>If you didn't change the using script to use the local copy of the include, it will still use the iCloud one.
Not sure I understand this, I used only the cloud storage, and made no change to the include call
I edited the file, saved it in the cloud (same name, same location), but the script loads the previous one.
now if I need to first delete a file before saving it ... ?? Or clear the cloud storage, that’s out of my nervous system tolerance :)
You said "local" iCloud, made me think you meant Local in the app. It should have picked up the change, as you say. Did you do the edit on the same device where you tested the script? I've found SB is picky about seeing iCloud updates across devices. Probably not suitable, as you said.
My Local path is totally empty, I was only using the "in app" iCloud. Everything was done using the same iPad. But I did load/save using Streambyter standalone and/or Streambyter Auv3. Which is probably the problem.
Anyway, MidiFire and Mozaic work very well for me. Next option would be to make my own little Midi apps, but I would then need a new MacBook Air, which isn't too bad with the M1 chip, but as long as apple will charge me 100$ a year just to use my own little apps, ... not a chance.
XCode on ipadOS could be a game changer. But having to code in C, objective-c and swift (almost wrote swhit) in the same project is not very appealing.
Writing plugins, midi or audio was so much easier using vst2.xx and win xxx
It may not help you, but I believe I've found the problem. After editing the include file, you MUST Install Rules to convert it to the internal format. Otherwise, the updated version is not Saved. I guess I always do that, just to be sure my edits are correct. Took a while to track down, but I could definitely reproduce the problem.
create it’s own virtual ports (not sure it’s possible with iOS)
Being able to read/write midi files
create user GUI, Mozaic would be more fun if you could create user layouts, add buttons, drop list, pics, ..
Both are badly missing string functions
The nice part about Atom’s JS scripts is that it uses JavaScript, not sure about atom, but a JS interpreter is already included in iOS, no need to re-envent the wheel , just need to add midi callbacks, timer, host callbacks...
Special functions could be used to share data with a host, would require some collaboration, but some standard message handling could be implemented, then free to the host to answer or not.
iPads are cool but in certain situations it’s a huge step behind 💃🕺
Unfortunately, I think that some of what you would like may be impossible for an AUv3, which runs in a sandbox inside a sandbox. Certainly interesting, if possible.
If Atom can write logs, export/import Midi files, read write files, open and communicate with any midi port (I/O).. any plug can do it.
And JavaScript is HUGE, I know pretty much nothing about js except it "sounds" like c/c++😻, a quick search on the net answers all my questions. Just type: itoa js
Both Drambo and SB have Global variables, and..
Off course a plugin script can inherit all the Auv3 spec.
There are probably some JS related limitation in a sandbox, but so far I didn't see any.
The only thing is : can an auv plug create a virtual midi port ? If not, MidiFire with 64 ports should do :)
@mbncp01 How did you open different MIDI ports from within ATOM2 AUv3?
I think @giku could answer the question about an AUv3 creating a virtual MIDI port.
Javascript is nice to work with but I wonder if the performance would be better than Mozaic. Some things just cannot be done with Mozaic because it's too slow.
Theoretically AUv3 can create and remove audio and midi ports, this array is dynamic, I even tried to do it (First drambo multi io beta version). In practice there is no host that supports this (even desktop AFAIK).
In Atom JS, you can have as many ports as you want
const INPUTS = [
"Arturia KeyLab Essential 88 MIDI In",
"Drambo"
"MidiFire 1"
];
const OUTPUTS = [
"Arturia KeyLab Essential 88 MIDI Out",
"Drambo",
"MidiFire 2"
];
The only problem is that OnNoteOn .. won't tell you which port sent the midi
midi.emit([.....]) you can't tell to which port to send. I don't think it's an iOS limitation, it's just blueveek being lazy, again :)
Joke aside, the JS in atom was made to communicate directly with a controller (launchpad) and in that case there is no real need for multiple ports. The problem is when using more that one controller or my Arturia keyboard 🙄sending the same stuff on both ports (I can't make a difference between the record button or a normal note on the keyboard).
>>Javascript is nice to work with but I wonder if the performance would be better than Mozaic. Some things just cannot be done with Mozaic because it's too slow.
Could try, a bit difficult with Mozaic as after a few for.. loops it yells at you.
You think python would be faster ? I remember that VBA (Visual Basic for application) was pretty fast as it was P code (pre-compiled).
Is it the same with python? If it is compiled , I don't think that iOS will let you run it, but then, what do I know about iOS ..?
Comments
Just made some test:
My keyboard -> Drambo
My keyboard -> Atom Script emit -> Drambo. // emit: atom sends to a midi port (drambo virtual in)
My keyboard -> Atom Script emit -> MIdiFire -> Drambo (drambo virtual in)
My keyboard -> Atom Script receive -> Drambo. // receive: bypasses Drambo routing, its like Atom generated the event
The receive midi will reach all atom instances that have Midi Thru enabled and either the clip is armed or the view is open
All show the same timestamp (buffer quantisation)
So that's pretty good news
@mbncp01 Are you running StreamByter in MIDIFire or as AUv3? I've only used it as AUv3, or stand-alone. I'll try it in MIDIFire and see if it performs differently.
No, no, was using it as Auv3 in AUM.
Good. I just tried it in MIDIFire and it does not work. The MIDIFire version cannot access the filesystem, so the Set include does not work.
It should work fine in AUM, provided you've stored the include file in StreanByter's iCloud with the correct name. In fact, when I load either the send or receive scripts, the numbers appear immediately, even before Install Rules. I assume you're loading the script using the hamburger menu in the lower right of the SB window. Does it display "iCloud is available" when you do that? If you're just seeing "--" where the numbers should be, you need to Install Rules to compile the program. That's when the initialization is executed.
If it still doesn't work, you could zip the files and post them here, so I can test with your exact code.
If I rename the include i get an error when calling init.. maps
In the include file, if after both LB0/1 I add another
Set LB0 111 # I can see 111
So the code is executed but it looks like something's wrong in the include file
OK. I may have confused you by adding the ".txt" extension. I only did that so you could load the file into a text editor, prior to copying the text to SB. When you invoke the SB save command, you must not use any extension. So, the steps are:
And, I just tried your file. After you paste the include text, you can compile it using Install Rules, even though it's not a complete program. The End after Set LB1 I1 is missing the "E", so it errors out. So that may be the problem.
Edit: used your copy of the include, corrected, with the send script, and looks OK.
@uncleDave
The missing E is just a typo, once I pasted in textedit I saw that I still had my Set LB0|1, and when cleaning I removed that E.
I just tried with Drambo and AB3, same result, both LB show zero.
If I have at the end of the include Init maps sub
Sub init.._maps
#bypassing the 2 calls
Ass L1 = 55
Set LB0 L1
End
it shows 0
There is a bug somewhere, which iPadOS are you using, myself I'm on 14.4.2 , Air4
Now I just tried to create a simple include file and a simple std script, just stating some var, and this works fine, in my main script I get the var correctly ... weird
Ok, but enough SB for today :)
That's annoying. I'm on iPadOS 14.4.2, iPad 6. StreamByter version 1.7, shown in the iPad Storage listing; doc in the app says 1.6. I don't think the Labels should ever show zero; they normally show "--" when not set. When you feel like it, post the script and the include file that don't work. As I said, your include file worked fine after I fixed the typo, so there must be a problem in the script.
@uncleDave
Deleted the app, removed the iCloud file too, new install, same scripts ... And finally I see the 17 and 3 😅
Will try tomorrow, but it should be fine now.
Excellent. You may have had an old copy of StreamByter. You should be on the way now.
I think the problem is in corrupted files. I changed the include file (only 2 CC) and stored it again on the "local" cloud.
Now it still shows me 17 3, which means it is still using the previous file, so there is really something fishy about the app itself.
Sorry, but I don't feel to spend anymore time on this. Mozaic works well in MidiFire with zero latency. I guess using streambyter is a bit more efficient, but from my tests, I didn't see any difference using either Mozaic or Streambyter( the midi timestamp within a host is always equal), and as I can code in Mozaic script without having to think about how I should code, streambyter is not really a priority.
IMO, the real interest would be if a streambyter script(used in MidiFire) could send to a specific midi port. From what I see it's only for UDP communication, which I don't use.
This reminds me Bidule where a filter module would have 2 outlets, one for the filtered events, one for the other, or 16 outlets, one for each channel, was great, though it wasn't perfect either. Now I'm not blaming any devs, creating a new app can be fun, but continuous FR, iOS changes, .. is a nightmare on the long run, unless to take the right medication :)
Did you change the "set inc icloud" in the script to "set inc local"?
No need to be sorry. You set the challenge, I answered it with a modular solution where one configuration can control both sender and receiver. I'm sure you'll enjoy working with Mozaic.
StreamByter in MIDIFire can send to any MIDI port, including the virtual ports configured by the app. You just set the wiring the way you want. You can send MIDI on different channels, then use two channel filters to route different channels to different ports. The UDP feature is an obscure optional feature, and its "port" parameter is a UDP port on another computer, nothing at all to do with iOS MIDI ports.
@uncleDave
No I didn't change it, exactly same files ( copy, paste, save..)
I mean routing inside the Streambyter module
If ...
send to Midifire1
else
send to midifire 2
Not the end of the world but an Au scripting tool with midi port connection would be something
Atom' s js script can do it , but you can't choose the output port :(
If you didn't change the using script to use the local copy of the include, it will still use the iCloud one.
You mentioned StreamByter used in MIDIFire. In the first configuration I posted, the StreamByter script could send messages on different MIDI channels. The two Channel Strips filter them to different MIDI ports, and can change the MIDI channel back to channel 1. This allows StreamByter to direct messages to different MIDI ports. So that meets your requirement, using the normal components of MIDIFire.
@uncleDave
I’m not a big fan of using midi channel on this type of op, as they already have a meaning, but I can embed one or more standard midi messsages in a sysex and the first byte would be the port to send to(blocking others).
>>If you didn't change the using script to use the local copy of the include, it will still use the iCloud one.
Not sure I understand this, I used only the cloud storage, and made no change to the include call
I edited the file, saved it in the cloud (same name, same location), but the script loads the previous one.
now if I need to first delete a file before saving it ... ?? Or clear the cloud storage, that’s out of my nervous system tolerance :)
You said "local" iCloud, made me think you meant Local in the app. It should have picked up the change, as you say. Did you do the edit on the same device where you tested the script? I've found SB is picky about seeing iCloud updates across devices. Probably not suitable, as you said.
My Local path is totally empty, I was only using the "in app" iCloud. Everything was done using the same iPad. But I did load/save using Streambyter standalone and/or Streambyter Auv3. Which is probably the problem.
Anyway, MidiFire and Mozaic work very well for me. Next option would be to make my own little Midi apps, but I would then need a new MacBook Air, which isn't too bad with the M1 chip, but as long as apple will charge me 100$ a year just to use my own little apps, ... not a chance.
XCode on ipadOS could be a game changer. But having to code in C, objective-c and swift (almost wrote swhit) in the same project is not very appealing.
Writing plugins, midi or audio was so much easier using vst2.xx and win xxx
It may not help you, but I believe I've found the problem. After editing the include file, you MUST Install Rules to convert it to the internal format. Otherwise, the updated version is not Saved. I guess I always do that, just to be sure my edits are correct. Took a while to track down, but I could definitely reproduce the problem.
@uncleDave
No offence @Nic, but WT..
Badly miss this:
Does anyone still have this in their file archive?
I think I still have the source code on my 20+ years old pc.
Anyway, I don’t think any host still supports mfx plugins, ocx, vba, .. and this was window only.
But compared to what this plug could do, Mozaic, StreamByter, Atom JS(not it’s intention), are very pale “clones” 😫😮
If @blueveek wants to go ahead with a JS midi plug, I don’t mind helping for 💯 u$ a year, ok 50 ... ok for free and I buy the app :)
@mbncp01 Oh cool, you're the developer?
I haven't found much info about mfxscript but my first thought was to build a MIDI processor using python MIDI libraries...
Which are some major features that neither Mozaic nor Streambyter can do?
IMO, a midi fx plug should be able to:
Connect to any midi port, not just the host
create it’s own virtual ports (not sure it’s possible with iOS)
Being able to read/write midi files
create user GUI, Mozaic would be more fun if you could create user layouts, add buttons, drop list, pics, ..
Both are badly missing string functions
The nice part about Atom’s JS scripts is that it uses JavaScript, not sure about atom, but a JS interpreter is already included in iOS, no need to re-envent the wheel , just need to add midi callbacks, timer, host callbacks...
Special functions could be used to share data with a host, would require some collaboration, but some standard message handling could be implemented, then free to the host to answer or not.
iPads are cool but in certain situations it’s a huge step behind 💃🕺
Unfortunately, I think that some of what you would like may be impossible for an AUv3, which runs in a sandbox inside a sandbox. Certainly interesting, if possible.
If Atom can write logs, export/import Midi files, read write files, open and communicate with any midi port (I/O).. any plug can do it.
And JavaScript is HUGE, I know pretty much nothing about js except it "sounds" like c/c++😻, a quick search on the net answers all my questions. Just type: itoa js
Both Drambo and SB have Global variables, and..
Off course a plugin script can inherit all the Auv3 spec.
There are probably some JS related limitation in a sandbox, but so far I didn't see any.
The only thing is : can an auv plug create a virtual midi port ? If not, MidiFire with 64 ports should do :)
@mbncp01 How did you open different MIDI ports from within ATOM2 AUv3?
I think @giku could answer the question about an AUv3 creating a virtual MIDI port.
Javascript is nice to work with but I wonder if the performance would be better than Mozaic. Some things just cannot be done with Mozaic because it's too slow.
Ah, I need to go through this thread :)
Theoretically AUv3 can create and remove audio and midi ports, this array is dynamic, I even tried to do it (First drambo multi io beta version). In practice there is no host that supports this (even desktop AFAIK).
In Atom JS, you can have as many ports as you want
const INPUTS = [
"Arturia KeyLab Essential 88 MIDI In",
"Drambo"
"MidiFire 1"
];
const OUTPUTS = [
"Arturia KeyLab Essential 88 MIDI Out",
"Drambo",
"MidiFire 2"
];
The only problem is that OnNoteOn .. won't tell you which port sent the midi
midi.emit([.....]) you can't tell to which port to send. I don't think it's an iOS limitation, it's just blueveek being lazy, again :)
Joke aside, the JS in atom was made to communicate directly with a controller (launchpad) and in that case there is no real need for multiple ports. The problem is when using more that one controller or my Arturia keyboard 🙄sending the same stuff on both ports (I can't make a difference between the record button or a normal note on the keyboard).
Ah, I need to go through this thread :)
@giku
Please, don't :)
@rs2000 wrote:
>>Javascript is nice to work with but I wonder if the performance would be better than Mozaic. Some things just cannot be done with Mozaic because it's too slow.
Could try, a bit difficult with Mozaic as after a few for.. loops it yells at you.
You think python would be faster ? I remember that VBA (Visual Basic for application) was pretty fast as it was P code (pre-compiled).
Is it the same with python? If it is compiled , I don't think that iOS will let you run it, but then, what do I know about iOS ..?
Now if we can script audio plugs .. 😈