Midi Out module converts 0x9n nn 00 to 0x8n nn 00
The problem is that the Mackie protocol (at least my Arturia keyboard) wants a NoteOn message with a velocity of 0, not a NoteOff.
The problem is that the Mackie protocol (at least my Arturia keyboard) wants a NoteOn message with a velocity of 0, not a NoteOff.
Comments
It seems to get converted on the way in too. I placed a Streambyter monitor as the first plugin, then sent Note-On zero velocity. It was converted to a note off.
Mozaic does this too, to reduce the confusion some people have over these two messages, which according to the midi spec are supposed to be exactly the same thing (and are both supposed to be supported).
Unfortunately mozaic converts on input, but not on output
the following code (host stop) used with AUM will work, but not with Drambo
@OnHostStart
SendMIDIOut 0x90, 94, 127
@End
@OnHostStop
SendMIDIOut 0x90, 94, 0
@End
Now I’m not sure that the Mackie protocol is that strict, but it is on my Arturia keylab 88 Essential keyboard :(
Yes, Mozaic automatically converts 0x90 at zero velocity to 0x80 (note off). It's no help for this problem.
You would need to use StreamByter outside of Drambo to convert 0x80 to 0x90 at zero velocity. StreamByter will be of no help inside Drambo.
Havn't tried yet, but an Atom scrip should do the trick, I already need one for receiving and sending sysex to my controller, as Drambo just ignores them. Also handy to send CC's back to Drambo used for midi learn (control). And no need to lauch another app.
Now I wouldn't mind a second or even a third Drambo Midi I/O port and a Midi In Module.
Aum gives you more freedom and choices, but complex routine becomes quickly a big mess, while with Drambo it's much "cleaner" and midi learn is really quick to setup. And being able to copy paste full racks quickly anywhere with minimal and easy re-connection is incredibly powerful.
@mbncp01 An Atom script? Can you give more details please?
To make a drambo loop, make a copy of Example.js , then set the ports
'
const INPUTS = [
"Drambo"
];
const OUTPUTS = [
"Drambo"
];
I use just some CC, but you can use any midi type:
function onCc(cc, value, channel, timestamp) {
midi.emit([0xB0 | channel, cc, value]);
}
you need at least one instance of Atom, and make sure the script is selected
That's an easy trick to send a CC to Drambo Control (midi mapping) without using external apps
you can have any number of in/ out ports, only problem, you don't know which port sended an event, plus on output it sends midi to all ports. That,s why I prefer to have different scripts.
Another trick is to receive midi on a track even if this track is not the active track
Put an atom clip on the track, disconnect it's midi in, either have it's view enabled or arm the clip for recording, then in a script set your input, don't need an output port, and this time:
function onCc(cc, value, channel, timestamp) {
atom.receiveCC(cc, value, channel, 0);
}
Atom will output that CC. Of course you can do what you want in the script, filtering, changing ..
Only problem with atom.receive*(..), is that any clip that has record enable or it's view is open will receive the event.
Basically an Atom script can receive and send midi (including sysex) from any port, with the receive trick it can even send midi out of any instances in a project. Coupled with Drambo modules, and/or Mozaic script, and avoiding infinite midi loopback :) , it's really powerfull.
Just with the drambo to drambo loop script, I can solo any active track with a single button/CC from my midi controller 8)
Edit: and off course in a script you can also control any instances of Atom, that was the idea of a scripting engine LOL
@mbncp01 I’ll freely admit I didn’t parse your entire script well enough to understand it fully, but that is because the issue as I see it is no script can solve this problem. No matter what you do in a script, before a Note-On at zero velocity will be converted to a Note-Off before it exits Drambo to go to a controller.
Unless, of course, your point is for Atom to talk directly to the controller. I guess that could work. I’ve written a custom controller script and it is indeed powerful.
Still, I think I’d solve this by a one line StreamByter script between Drambo’s output and the controller. Something that simply converts note-off to note-on at zero velocity.
In my case it is just a question to turn the leds ON on my controller.
I found out the sysex required to lit any button and even write text (2x18 char display) on the keylab, so yes Atom will deal with that.
Finally I will use these buttons, mainly to control Atom, and use my qwerty keyboard to control Drambo.
Actually I even removed my controller port from Drambo, an Atom script will deal with everything.
Thanks to the display on my controller, I will be able to use all these buttons, knobs, fader for different task. Atom, instruments, flexi, volume, pans, fx.. hold a special button, touch any other button, fader,.. and I will see a description of what it does 😎, before messing up everything 😅
Interesting, thanks @mbncp01.
I wish I could use Atom/Atom 2 seriously but the complete lack of pitch bend and CC support keeps me using LK and Streambyter instead.
@number37 , @rs2000
I try to avoid using Streambyter, it's my last resort insurance .
Are there any apps with more than one virtual midi port ? I could use a few.
Atom was probably released a bit early, I too miss PB and CC, but I hope it won't be too long ...
MIDIFire lets you create up to 64 virtual in/out port pairs. It lets you transform MIDI from the inputs and send it to any of the output ports. Built-in modules handle common operations, and StreamByter is included for the toughies.
Damm, almost 0.0002 Bitcoins
I always had in mind that MIDIFire was the predecessor of Streambyter.
Thanks, looks really good.
I guess I need to connect MidiFire 1 In to MidiFire 1 Out, or is it like Streambyter ?
Sorry just being lazy, I can figure it out myself
MidiFire is like a modular MIDI environment. I don't need it too often but when I do, it's a priceless utility 👍🏼
For me it will be very handy to communicate between atom scripts, Mozaic scripts and Drambo Tracks and Control
I was going to use Channels for that but it's a bit of a nightmare, so thanks again for pointing me to MidiFire 😍
It would be great to rename the ports, but a Post-It will do.
Edit: I was a bit worry it doesn't support sysex, but it does 🙏
Yes, StreamByter was born in the earlier MIDIBridge, ported to MIDIFire, then released as a separate component.
You don't have to connect MIDIFire 1 In to MIDIFire 1 Out. You can rig any connections you want, depending on the requirements of the other apps. Not sure what "like StreamByter" means in this context; I only use SB as an AUv3, so it just receives and sends on the connected paths.
There's a very nice (and long) manual describing all the functionality.
I see it's much deeper than I thought, I will probably use a few modules, especially filters, but I never made it with StreamByter coding.
I'm too much used to standard programming, my two brains just say NO WAY ... LOL
I find SB programming easy, and I spent 50 years doing "standard programming". It requires a different mindset. You're presented with MIDI events, one at a time. You need to decide whether to change the message, send other messages, remember stuff, etc. You can use aliases to place named variables in the arrays. You do need to be careful, and logical, with data management; essentially, you're doing the work of a compiler. And the simple statement structure is reminscent of early Basic; a keyword on every line.
Hmmm, ready for a challenge ? Just kidding but is this possible with streambyter ?
Convert some cc's to note and then back to cc (2 scripts), without doing any damage to incoming note on/off
For CC's like the Sustain pedal, it's simple, but for continuous CC like the mod wheel you need to
If it's one of our CC
1) Increase the second data byte by 1 as we can't use a velocity of zero for note on
2) Add a "fake" note off with a short delay
To convert back to CC
1) decrease the velocity by 1, except for 127 (we loose values of 126, but better than loosing 127)
2) ignore the note off value (if it's from one of our converted CC )
It would be even better to use a few notes for each CC, to avoid overlaps.
And it gets even a little more tricky with pitch wheel and key aftertouch, as we need 2 notes per event
@mbncp01 Conditionals, message dissection and composition, delays etc, StreamByter has it all.
My slow pace with SB is rather about finding the right commands in the documentation.
Aliases can help, I was just too lazy to build my own favorite default set...
@rs2000
Just checked the doc(again) and it does look quite powerful, but trying to learn and remember these "very" short commands is just too much for me.
If it had at least some menus or programming helps, it would have been another story.
Anyway, I'm really happy that we have all these apps on iOS. I wanted to make some app myself but learning a new OS(never coded on osx), new language, new tools, an old and very slow MacBook Air, was also too much. So thanks to these devs !
You don’t really have to remember a lot of commands if you understand the basic concepts behind them. That said, I prefer Mozaic and Atom 2 scripting. There is a lot to be said for how much work one can get done in just a one or two line script in StreamByter compared to the amount of code to do the same in those two.
Do you know if it's safe to run a Mozaic script with "zero latency" in MidiFire ?
It could be a good point to dig a little more into StreamByter.
I believe the attached should do the trick. Instead of adding one to the CC values, I sacrifice the value 1, converting any zero to 1, and converting all ones back to zero. Seems cleaner. It includes prototype support for aftertouch and pitch bend as well.
@uncleDave
Nice coding, I didn't even know they were subs
But I don't know what I did wrong, I pasted the 3 scripts in Streambyter, each with the exact name, on iCloud, but I don't see a StreamByter folder on iCloud.
On StreamByter, iCloud I can see the 3 files .. ?
StreamByter uses iCloud internally. There is no visible folder, you can only access it from StreamByter. I believe it was written a while ago, and it strongly embraces the sandbox tradition. StreamByters on any host using the same Apple ID can see these files. As I said in the README, the key advantage is that both stand-alone and AUv3 can see the the same iCloud files, which is not the case for Local. BTW, iCloud and iCloud Drive are not exactly the same. You're probably looking at iCloud Drive.
Thanks, by the way. Hope it gives you some ideas.
@uncleDave Ok got it, thanks 😅
Trying with AUM, Pitch Bend, CC85, but IN and OUT have the same values, I don't see generated Notes
Same result with StreamByter standalone.
The include has to be named "CC_note_map_include" without "" , is this correct ?
Yes, no quotes. You'd know if it didn't include. Did you remember to Install Rules after loading the send script? That's what compiles the script. If it loaded properly, you should see two numbers in the middle of the bottom, as shown
The first is the number of CCs (17 in my sample), the second is the number of specials, 3 in my case. Those are set by the map initialization functions when they run.
Incidentally, once you save StreamByter in an AUM preset, or whatever, it will "just work" when you load the preset. No need to Install Rules unless you change the code.
@mbncp01 I just noticed that you can see the files StreamByter stores on iCloud. Tap on your Apple ID, at the top of Settings, then Apple ID–>iCloud–>Manage Storage–>StreamByter. That's the StreamByter private storage. You cannot access those files, but you can delete them.
@uncleDave
I don't get compiling errors so it does find the include file but both labels show zero (using your original script), don’t know what I’m doing wrong.
At least this makes me dig a little more. I see how interesting it can be once you don’t have to check the manual.
Found the files, forgot about this iCloud storage
Now I’m having some concerns about using MidiFire, sending midi from aum or drambo to Midifire and back to them takes about 2 audio buffer, 20 msec in my case, it looks like these host delay sending midi out at the beginning of the next buffer :(