Yahoo Groups archive

Elektron Musical Instruments

Index last updated: 2026-04-28 23:22 UTC

Message

[elektron] Re: recording the locks

2002-10-07 by daniel_elektron

--- 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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.