Hi there,
I'm just wondering if MIDI over USB is faster (in terms of transfer speed) than using the regular MIDI ports ?
Background: Assuming that it *is* indeed faster, shouldn't it be possible to use SYSEX messages to add further controllers?
Example: I played around with the mod sequencer and used it to create C=64 style arpeggios. Since it isn't possible to switch between different mod sequences (in one timbre), I realized that I'd have to alter the mod sequence via SYSEX in order to achieve different chords (like 0-3-7 for minor, 0-4-7 for major and so on). I guess there are lots of other use cases.
Btw, I borrowed the R3 from the music store downstairs some hours ago and I really must say that it sounds fantastic ! I'm definitely going to order its bigger brother (RADIAS-R) tomorrow (:
geeky: Is USB MIDI faster than regular MIDI ? (->sysex ct
Moderators: Sharp, X-Trade, Pepperpotty, karmathanever
USB Speed vs. MIDI
MIDI runs at 31.250 Kbs
USB 1.0 Low is 1.5 Mbs
USB 2.0 is 480 Mbs
USB can transport the data faster that's for sure!
USB 1.0 Low is 1.5 Mbs
USB 2.0 is 480 Mbs
USB can transport the data faster that's for sure!
Theoretically this is true. On the other hand, there are other factors that may limit the effective speed, for example how fast the device can actually process the MIDI data.
I also wonder what happens if a MIDI cable is plugged into the "thru" port. If the device receives MIDI data over USB at >1MBs, it would have trouble to relay that data to the slower MIDI port at the receive speed, wouldn't it?
I could imagine that the device is able to detect whether there is a cable plugged or not and adjust the receive speed accordingly..
By just measuring the time it takes for the R3 PC editor to "Receive All Data" I would assume that the USB MIDI is at least 3-4 times faster.
Unfortunately, I will not get my own Radias until October so I'll have to wait to try it out for myself.
Besides using SYSEX to add additional controllers (e.g. modify the above-mentioned mod sequence data or control FLT2 Resonance), I'd love to use it to switch the timbre program data "on-the-fly"; i.e. instead of using a program change (which would change all timbres and FX1/2 setups or am I mistaking here?!), I'd like to use SYSEX to just reprogram a single timbre (all the things that are listed in Table7 of the Radias SysEx docs).
The timbre program data is 92 bytes, along with the sysex header it would take ~100/(31250/8) = 100/3906 = 0.0256 seconds to send this over a regular MIDI port, over USB it might be a lot faster thus making it possible to use it to switch "instruments" in real-time. Just an idea, though
Has anyone tried something similar before resp. is there a reason why this will not work in practice ?
Edit: As far as I understand the docs, changing timbres should be possible without using SYSEX, right ?!
I also wonder what happens if a MIDI cable is plugged into the "thru" port. If the device receives MIDI data over USB at >1MBs, it would have trouble to relay that data to the slower MIDI port at the receive speed, wouldn't it?
I could imagine that the device is able to detect whether there is a cable plugged or not and adjust the receive speed accordingly..
By just measuring the time it takes for the R3 PC editor to "Receive All Data" I would assume that the USB MIDI is at least 3-4 times faster.
Unfortunately, I will not get my own Radias until October so I'll have to wait to try it out for myself.
Besides using SYSEX to add additional controllers (e.g. modify the above-mentioned mod sequence data or control FLT2 Resonance), I'd love to use it to switch the timbre program data "on-the-fly"; i.e. instead of using a program change (which would change all timbres and FX1/2 setups or am I mistaking here?!), I'd like to use SYSEX to just reprogram a single timbre (all the things that are listed in Table7 of the Radias SysEx docs).
The timbre program data is 92 bytes, along with the sysex header it would take ~100/(31250/8) = 100/3906 = 0.0256 seconds to send this over a regular MIDI port, over USB it might be a lot faster thus making it possible to use it to switch "instruments" in real-time. Just an idea, though
Has anyone tried something similar before resp. is there a reason why this will not work in practice ?
Edit: As far as I understand the docs, changing timbres should be possible without using SYSEX, right ?!
Got my Radias today and guess what.. one of the first things I tried is to answer my question.
I have modified my tracker/sequencer (which I am currently working
on but that's another story) to send 80 parameter change sysex
requests to the Radias every 4 ticks (125 bpm, 96 ppq) i.e. ~50 times
per second (i.e. 80*12 = 960 bytes, this alone would take 245.76ms
seconds with a regular MIDI serial port, with USB it seems to take
less than 20!).
The result is: No note drops when playing a simple sequence! *WEEE*
I hope I did not make any mistakes
...but if this is for real then this is automation heaven and opens up
a whole new world of possibilities (just think of the way "oldskool"
sound players reprogrammed the sound chips rapidly to achieve envelopes, sound fx etc..)
Besides,
80 program changes are only needed if almost every timbre parameter
is changed..
I will keep investigating this but if everything is as it seems then the Radias is sure to get some extra attention/support in my tracker *FG* !
Tomorrow I will try to find out how the machine likes frequent "current program data dump"s...that would be ~104 bytes to change all timbre program data params resp. ~226 bytes for all timbre params (i.e. a lot less than sending all params via parameter change)
If anyone from Korg is reading this, could you please comment?
I'd like to know whether it is possible to disable the DATALOADCOMPLETED sysex replies (e.g. to PARAMETERCHANGE) in order to save some CPU/DSP time in the Radias.
Hmm it seems that the Korg devs forgot to implement the following
sysex functions:
"CURRENT TIMBRE PARAMETER DUMP REQUEST" (receive)
"CURRENT TIMBRE PARAMETER DUMP" (send+receive)
"CURRENT TIMBRE PROGRAM DATA DUMP REQUEST"
"CURRENT TIMBRE PROGRAM DATA DUMP" (send+receive)
+ several others to exchange subgroups of a program (e.g. only insertfx, only modsequence etc..)
However, after studying the docs I found out that most of the timbre
parameters can be changed via CCs.
This cuts down the amount of data that needs to be sent to (almost) change all sound-gen. parameters (of one timbre) by around factor 6 (sysex param change size is 12 bytes, CC with running status is just 2).
Nice.
The mod sequence can obviously be changed via NRPN messages, this will do fine.
In case you are wondering why I am doing this:
I want to save the instruments with a song so that they are loaded when the song is loaded. I want the instruments to be only uploaded to the RAM of the Radias (i.e. they will never be written to Flash. I am a bit worried that the flash memory gets worn out if it is written everytime a song is loaded or when an instrument has been edited).
Furthermore, I'd like to use the sysex paramchange, NRPN and CC messages to be controlled by sequencer envelopes which are started
e.g. by noteon events in the sequencer (e.g. control the waveshape parameter with a "software" envelope in addition to the 3 Radias "hardware" envelopes).
I will have to investigate how the parameter changes affect current sounding voices (until now I noticed that e.g. changing "transpose" has
no effect on already triggered voices while e.g. flt1cutoff has).
I think I will now try to code an "intelligent" program/timbre change
routine that will work as follows (assumes that each "sequencer instrument" stores a Radias program dump but only really considers one timbre of that program):
1) The first time a sequencer instrument selects a timbre program, upload the program data for all timbres to the Radias (since it is not possible to just upload one timbre)
2) When a new sequencer instrument is selected, compare the new timbre data to the one the Radias already has and just send the differences via CC, NRPN and Sysex ProgramChange.
If this turns out to work fine (i.e. no sound lags/note drops) the next step
would be to combine this with "regular" program changes: The sequencer would have to receive all programs from the Radias and so that it can copy the program timbre to its internal "program state" when a regular program change occurs (as far as I understood, the Radias can change a single of the current program to the timbre (1..4) of another program). This will be necessary in order to make the "delta" updates work..
I bet many of you are utterly confused now but believe me, this is FUN
p.s.: Are the updated sysex docs for the new v2 firmware already available ?
sysex functions:
"CURRENT TIMBRE PARAMETER DUMP REQUEST" (receive)
"CURRENT TIMBRE PARAMETER DUMP" (send+receive)
"CURRENT TIMBRE PROGRAM DATA DUMP REQUEST"
"CURRENT TIMBRE PROGRAM DATA DUMP" (send+receive)
+ several others to exchange subgroups of a program (e.g. only insertfx, only modsequence etc..)
However, after studying the docs I found out that most of the timbre
parameters can be changed via CCs.
This cuts down the amount of data that needs to be sent to (almost) change all sound-gen. parameters (of one timbre) by around factor 6 (sysex param change size is 12 bytes, CC with running status is just 2).
Nice.
The mod sequence can obviously be changed via NRPN messages, this will do fine.
In case you are wondering why I am doing this:
I want to save the instruments with a song so that they are loaded when the song is loaded. I want the instruments to be only uploaded to the RAM of the Radias (i.e. they will never be written to Flash. I am a bit worried that the flash memory gets worn out if it is written everytime a song is loaded or when an instrument has been edited).
Furthermore, I'd like to use the sysex paramchange, NRPN and CC messages to be controlled by sequencer envelopes which are started
e.g. by noteon events in the sequencer (e.g. control the waveshape parameter with a "software" envelope in addition to the 3 Radias "hardware" envelopes).
I will have to investigate how the parameter changes affect current sounding voices (until now I noticed that e.g. changing "transpose" has
no effect on already triggered voices while e.g. flt1cutoff has).
I think I will now try to code an "intelligent" program/timbre change
routine that will work as follows (assumes that each "sequencer instrument" stores a Radias program dump but only really considers one timbre of that program):
1) The first time a sequencer instrument selects a timbre program, upload the program data for all timbres to the Radias (since it is not possible to just upload one timbre)
2) When a new sequencer instrument is selected, compare the new timbre data to the one the Radias already has and just send the differences via CC, NRPN and Sysex ProgramChange.
If this turns out to work fine (i.e. no sound lags/note drops) the next step
would be to combine this with "regular" program changes: The sequencer would have to receive all programs from the Radias and so that it can copy the program timbre to its internal "program state" when a regular program change occurs (as far as I understood, the Radias can change a single of the current program to the timbre (1..4) of another program). This will be necessary in order to make the "delta" updates work..
I bet many of you are utterly confused now but believe me, this is FUN
p.s.: Are the updated sysex docs for the new v2 firmware already available ?
so good so far.. the "incremental timbre update" works so far (as described above)..takes 405 midi bytes to change from "init timbre" to the v1.02 VeloSyncLead timbre (w/o insertfx, modsequence data, though)
I stumbled over a few minor issues regarding parameter updates via CCs;
couldn't persuade the Radias to make the following CCs do what I expected them to do:
- Unison SW (cc #3)
- Osc1 Mod (cc #9)
- Osc1 Wave Type (cc #8)
- Osc2 Mod Select (cc #19)
- Osc2 Wave Type (cc #18)
- Filter 2 Type (cc #29)
- Filter Routing (cc #26)
- LFO 1 Wave (cc #89)
- LFO 2 Wave (cc #102)
..I passed the respective values from the program dump to the controllers but it did not have the desired effect so I had to resort to
sysex parameter changes to set these parameters..known issue or my mistake ?! (one thing all these params have in common is that they are bitfield members..)
I am wondering if it is worth the effort to treat the drumkit just like additional 16 "mono" timbres (which they technically are) in my sequencer , i.e. in a way that you can play melodies with a drumkit timbre if you catch my drift..
Another "geeky" thing I am thinking of is to create an instrument mode where the envelopes are calculated by the sequencer and which allows you to create a step-sequence that allows to change e.g. the oscillator waves in each step; this would require to retrigger the voice ~50 times per second (that's why the radias envelopes wouldn't work). If it works, this could be used to create cool C64 "chipmusic" style sounds
Well, I am sure that I am boring the majority of you readers with this technical "gebrabbel"..maybe you will be able to try it out for yourself this x-mas..
Cheers.
(w/o insertfx, modsequence data, though)I stumbled over a few minor issues regarding parameter updates via CCs;
couldn't persuade the Radias to make the following CCs do what I expected them to do:
- Unison SW (cc #3)
- Osc1 Mod (cc #9)
- Osc1 Wave Type (cc #8)
- Osc2 Mod Select (cc #19)
- Osc2 Wave Type (cc #18)
- Filter 2 Type (cc #29)
- Filter Routing (cc #26)
- LFO 1 Wave (cc #89)
- LFO 2 Wave (cc #102)
..I passed the respective values from the program dump to the controllers but it did not have the desired effect so I had to resort to
sysex parameter changes to set these parameters..known issue or my mistake ?! (one thing all these params have in common is that they are bitfield members..)
I am wondering if it is worth the effort to treat the drumkit just like additional 16 "mono" timbres (which they technically are) in my sequencer , i.e. in a way that you can play melodies with a drumkit timbre if you catch my drift..
Another "geeky" thing I am thinking of is to create an instrument mode where the envelopes are calculated by the sequencer and which allows you to create a step-sequence that allows to change e.g. the oscillator waves in each step; this would require to retrigger the voice ~50 times per second (that's why the radias envelopes wouldn't work). If it works, this could be used to create cool C64 "chipmusic" style sounds
Well, I am sure that I am boring the majority of you readers with this technical "gebrabbel"..maybe you will be able to try it out for yourself this x-mas..
Cheers.