--- In elektron-users@y..., Adam Watson <adam@s...> wrote: > Hmmm. Maybe Elektron means that this is more an issue with the > *amount* of MIDI data being sent is certain high-load situations, > as opposed to the delay of a single parameter lock being sent. In > other words, if a majority of the machines in a kit had a lock on > multiple notes at once, the MIDI traffic could be extremely high > considering all MIDI data on the MachineDrum is sent as CCs and > not as NRPNs. > Perhaps this could be a potential source of delays. It could > possibly be an issue of MachineDrum just simply not being able to > process all the data in time to playback properly. The amount of CC data when maxing out on parameter locks would be extremely high and the MIDI bandwidth could not handle it, nevertheless handle it in time. Try do the calculations on 64 locks in 2x speed mode for two adjacent trigs. MIDI speed is 31.25 kbps, one byte takes 10 bits, and one CC minimum 2 bytes. If we transmitted parameter locks we'd need to filter the output for eventual high traffic situations and drop out on data or the MIDI cue would just add up. And it doesn't take situations as extreme as this to allow for audible timing problems. How much delay can you take? Take this time and calculate how many locks you can transmit (one CC takes either 1 ms and 0,64 ms, depending if the previous message was a CC or not). Personally I couldn't accept more than 5-6 ms delay, perhaps less if we're talking about a sharp filter change. That means a maximum of 5-10 CC's per step. Note-on for drum trigs uncounted. If you say you don't have any problems adding locks while sequencing externally you have probably limited yourself to these figures. But what were we to do if the user uses more locks? It wouldn't sound the same after recording and replaying from external. And in high traffic situations as described above we'd need to drop out which would mess up everything. And if you suggest we'd collect the CC's that are sent over between trigs that's not a very good idea as well, as that would prevent you from doing smooth sweeps from outside. Leaving us to a special NRPN system for trigs which would take more bandwidth and limit the number of possible locks even more. The MIDI channel business is a non issue here as it takes the same amount of time to transfer on any, and you can not transmit simultaneously, only serial, as MIDI is a serial protocol. And CC is faster than NRPN as NRPN generally is two CC messages. I hope that the explanation above gives you a better idea of why we say it is "impossible" to allow the locks to be transmitted by MIDI, even though it could work acceptably in certain limited situations! Daniel Hansson, Elektron
Message
[elektron] Re: recording the locks
2002-10-07 by daniel_elektron
Attachments
- No local attachments were found for this message.