|
|
Post by asutula on May 9, 2020 22:54:44 GMT
I'm running the StreamByter AU inside apeMatrix along with Rozeta X0X AU sequencer. I'm using StreamByter to map specific notes coming out of X0X to a new midi channel and note, sending the resulting messages to the midi out and a hardware drum machine. I was having problems and then, using the midi monitor in apeMatrix, saw that the notes coming out of StreamByter were an octave too high. Using monitoring both inside StreamByter and in apeMatrix, I can see that in order to get the desired note output to midi out (C4 for example), I have to send a note out of StreamByter one octave lower than the desired note (C3 for example). I've attached an image showing the midi monitoring of the same event inside and outside StreamByter. Here is my script: # Xox to drm1
NX 3C = X0 3C # bd to ch1 bd
NX 3D = X4 3C # sd to ch5 sd
NX 3E = X7 3C # cp to ch8 cp
NX 3F = X1 3C # lt to ch2 drm1
NX 40 = X2 3C # mt to ch3 drm2
NX 41 = X3 3C # ht to ch4 multi
NX 42 = X5 3C # ch to ch6 hh1 closed
NX 43 = X5 3E # oh to ch6 hh1 open
 Any ideas what could be going on here? I'm relatively new to midi on the iPad and new today to StreamByter, so sorry in advance if there is just something basic I'm not understanding. Thanks! |
|
|
|
Post by asutula on May 9, 2020 23:18:03 GMT
I was able to load the same setup in Audiobus 3 and see the same behavior
|
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on May 10, 2020 9:48:57 GMT
Hi asutula , All my apps use the yamaha convention for note numbering (C-2 to G8) where middle C is named as C3 whereas apematrix is using the roland convention where middle C is named as C4. Both are the same MIDI note number (60 or hex 3C) - it's just the way each of us are mapping the note number to a name. I chose to use the yamaha convention in my apps because that is what I know best and also the hex value for C3 is 3C, so easy to remember. According to your monitor output, StreamByter is doing what it has been told. This rule: NX 3C = X0 3C # bd to ch1 bdis coming into play and you can see the incoming channel is channel 10 but the outgoing channel is channel 1, so that rule remapped the channel. Your drum machine is probably also using the roland convention, so assuming your issue is that the drums are not being triggered you might need to drop your rules down an octave (just subtract 12 decimal from each note number in the remap side of each rule): # Xox to drm1
NX 3C = X0 30 # bd to ch1 bd
NX 3D = X4 30 # sd to ch5 sd
NX 3E = X7 30 # cp to ch8 cp
NX 3F = X1 30 # lt to ch2 drm1
NX 40 = X2 30 # mt to ch3 drm2
NX 41 = X3 30 # ht to ch4 multi
NX 42 = X5 30 # ch to ch6 hh1 closed
NX 43 = X5 32 # oh to ch6 hh1 openAlthough, I would have thought you want to keep the channel at 10 for the drum machine and just remap the notes the sequencer produces to the notes your drum machine expects, so I am not sure the above would work in any case. Regards, Nic. |
|
|
|
Post by asutula on May 10, 2020 15:37:21 GMT
Hi Nic, thanks so much for your reply. That explains my confusion perfectly... I didn't know there is more than one convention for note naming.
When I originally wrote my StreamByter script, I wasn't getting any notes remapped/triggered because of this confusion, but I did get it working by trial and error and using the midi monitors. So yea, that script I posted works, but I just wanted to understand the discrepancy in the note names between the two midi monitors. Fixing it wasn't enough, I had to know why haha!
I remap each note to a different midi channel because of the specific way I have that drum machine set up with another sequencer (hardware, the Squarp Pyramid, which also uses the Roland note naming convention, adding to my confusion even more), just personal preference.
Anyway, thanks again for the explanation.
|
|
