Elektron Musical Instruments

I saw a post not too long about this, but nobody answered so I'll ask 
it again.  Is there any way to get the MD to spit out parameter lock 
values to its MIDI out?  I'd like to record patterns / songs in 
Cubase, _with_ all of my parameter lock noodles.  If not, the manual 
says that "All machine parameters .. are accessible from MIDI control 
change messages" - why can't the MD translate it's locks to CC's and 
output them?

I love programming the MD with it's built in interface, but I'd like 
to be able to take my patterns and add some complexity in Cubase... 
maybe in a future OS upgrade?

-gerald

--- In elektron-users@y..., "oldmanfury" <erinys@s...> wrote:
> 
> I saw a post not too long about this, but nobody answered so I'll 
> ask it again.  Is there any way to get the MD to spit out parameter 
> lock values to its MIDI out?  I'd like to record patterns / songs 
> in Cubase, _with_ all of my parameter lock noodles.  If not, the 
> manual says that "All machine parameters .. are accessible from 
> MIDI control change messages" - why can't the MD translate it's 
> locks to CC's and output them?

  Nope.

  I e-mailed Elektron about this, and requested that they add it to a 
future version.  They wrote back and said that it's impossible, as 
MIDI delays will cause the notes to not sound correct...

  I totally disagree; I program my parameter lock messages in by hand 
to my sequencer and when I play them back out it sounds great... Oh, 
well.

>   I totally disagree; I program my parameter lock messages in by 
hand 
> to my sequencer and when I play them back out it sounds great... 
Oh, 
> well.


I believe you're thinking wrong here :

when the parameter lock messages are sent by your sequencer, it is at 
what we could call the "same time" than when the note on message was 
sent (let's say delay will be unnoticeable)
But when the note on comes from the sequencer, it goes down your midi 
cables to the MD, then the MD understands it has to trigger some 
machines. Next stage is processing the parameters of the machine and 
maybe formatting the outgoing "parameter lock" MIDI message.
I believe that takes some time and then we go from "unnoticeable" 
to "the MD is going nuts, MIDI is spaced out, why can't these guys at 
Elektron do their job well ??". But they are doing their job OK 
telling you that this or this feature cannot be implemented.

as far as I am concerned : I program my parameter lock messages in by 
hand to my sequencer and when I play them back it sounds great... but 
my sequencer is the MD :)

Having said this, I would really like the MD to "spit out" its 
parameter locks as well..

Xavier

--- In elektron-users@y..., "merlinpipo" <yapp@c...> wrote:

> when the parameter lock messages are sent by your sequencer, it is 
> at what we could call the "same time" than when the note on message 
> was sent (let's say delay will be unnoticeable)

  Actually:  If I have more than say three locks on a particular 
note, I'll try to put one or two of them one click BEFORE the actual 
note, thereby avoiding any delay problems.  It works...

> maybe formatting the outgoing "parameter lock" MIDI message.
> I believe that takes some time and then we go from "unnoticeable" 
> to "the MD is going nuts, MIDI is spaced out, why can't these guys 

  According to Elektron, it takes 1 millisecond.

> as far as I am concerned : I program my parameter lock messages in 
> by hand to my sequencer and when I play them back it sounds 
> great... but my sequencer is the MD :)

  My sequencer is an MPC2000XL.

> Having said this, I would really like the MD to "spit out" its 
> parameter locks as well..

  Next question:  How to make it spit out "slide" as a MIDI 
parameter?  Or is that already implemented?

> > maybe formatting the outgoing "parameter lock" MIDI message.
> > I believe that takes some time and then we go from "unnoticeable" 
> > to "the MD is going nuts, MIDI is spaced out, why can't these 
guys 
> 
>   According to Elektron, it takes 1 millisecond.
> 

that should be OK if 1 millsecond is the time required to process the 
parameter lock for all machines. If not, then we may have to face a 
delay ranging between 1 and 16 milliseconds. In the latter case, that 
would in fact produce some noticeable drops in the sounds.
But maybe I am talking a bit too much about something that doesn't 
exist ;)

Xavier

Once upon a time, Mind wrote:

MM> \ufffd I e-mailed Elektron about this, and requested that they add it to a 
MM> future version.\ufffd They wrote back and said that it's impossible, as 
MM> MIDI delays will cause the notes to not sound correct...

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.

Still doesn't quite make sense, though. Just like you, I can very
easily send control changes to the MachineDrum very easily from Logic,
even in heavy-traffic situations, without any problems, slowdowns,
and/or midi traffic or processing issues...


MM> \ufffd I totally disagree; I program my parameter lock messages in by hand 
MM> to my sequencer and when I play them back out it sounds great... Oh, 
MM> well.

If it were simply a matter of delayed playback of the parameter locks
when coming from an external sequencer, then this should be a matter
left up to the user... I mean, it would be very easy to put a negative
delay on the parameter locks in your external sequencer, so that they
get sent a few milliseconds sooner than usual to avoid delayed
playback.

No, I think this is more a technical issue with the parameter lock
implementation - otherwise Elektron would have already implemented
these features, since this seems to be a pretty highly wanted feature.

I, too, wish that something about this could be changed so that it was
possible to send parameter lock information to an external sequencer.


-- 
Best regards,
Adam Watson

soundwithin
www.soundwithin.net

--- In elektron-users@y..., Adam Watson <adam@s...> wrote:

> 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 

  NRPNs use up less MIDI data than CCs?

">   My sequencer is an MPC2000XL."

How do you use the md with that?  I have the older mpc2000, but 
haven't touched it since I got the md two weeks ago.  Do you just use 
the mpc's timer and run the md alongside?  Can you play the drums on 
the md with velocity changes from the mpc, I guess not (it should 
be)?  But I'm sure you can play the different drums without running 
the md!  I'm in the process of cleaning and rearranging my "studio".  
Tell me how you do it.

The main problem about this, is that the MD sends and receives in 4 
different midi channels. To be able to do this you\ufffdd have to be able to 
record 4 simultaneous midi tracks , each receiving it\ufffds own (and only) 
channel. This is a bitch really... The best way to do this is to work all 
your sequences in the MD and record them to audio. At least this is what I\ufffdm 
doing. I tryed to create a system that would let me work  midi based but 
neither cubase nor sonar would let me do it.
The midi delay problem could be rounded. First you \ufffdd record your data to 
the external sequencer, and then when playing back, you\ufffdd have to use a 
blank pattern but with the same kit loaded. This would do the trick.
The 4 midi channel sh*t would be the worst part of it... any ideas?
Rui



>From: "Mind Mechanic" <machanic@...>
>Reply-To: elektron-users@yahoogroups.com
>To: elektron-users@yahoogroups.com
>Subject: [elektron] Re: recording the locks
>Date: Sun, 06 Oct 2002 23:45:30 -0000
>
>--- In elektron-users@y..., "oldmanfury" <erinys@s...> wrote:
> >
> > I saw a post not too long about this, but nobody answered so I'll
> > ask it again.  Is there any way to get the MD to spit out parameter
> > lock values to its MIDI out?  I'd like to record patterns / songs
> > in Cubase, _with_ all of my parameter lock noodles.  If not, the
> > manual says that "All machine parameters .. are accessible from
> > MIDI control change messages" - why can't the MD translate it's
> > locks to CC's and output them?
>
>   Nope.
>
>   I e-mailed Elektron about this, and requested that they add it to a
>future version.  They wrote back and said that it's impossible, as
>MIDI delays will cause the notes to not sound correct...
>
>   I totally disagree; I program my parameter lock messages in by hand
>to my sequencer and when I play them back out it sounds great... Oh,
>well.
>




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Once upon a time, Mind wrote:

MM> \ufffd NRPNs use up less MIDI data than CCs?

Actually, no... in rereading my post, my statement was just a little
unclear. Sorry about that. What I was intending to get at was that by
using NRPNs, all control change information could be processed by only
using a defined set of CCs on a single MIDI channel, versus filtering
and processing CCs across 4 MIDI channels. I probably should have used
a more appropriate term like "processing bandwidth" versus
"traffic"...

On the other side of the coin, I do appreciate Elektron using only
CCs, as this makes programming utilities or creating editors for the
unit much more straightforward than having to deal with NRPNs.

Still wonder what the real reason for not being able to record
Parameter Locks is, though...



-- 
Best regards,
Adam Watson

soundwithin
www.soundwithin.net

--- In elektron-users@y..., "endlessnessisticman" 
<endlessnessisticman@y...> wrote:
> ">   My sequencer is an MPC2000XL."
> 
> How do you use the md with that?  I have the older mpc2000, but 

  I have the MPC set up to transmit MIDI clock; the MD is set up as 
slave.

  I create a pattern with the MD's sequencer (can't get easier than 
using a step sequencer!), then I record the MIDI notes into the MPC, 
generally using one track for each sound (one MPC track for BD, one 
for SD, one for LT, one for MT, etc, etc..) 

  When I'm all done creating/recording all of my variations and 
tracks, I totally blank out the pattern in the MD.  Then I press play 
on the MPC, go into the Track Mute screen, and jam :)

  I'll also generally program the first track of the sequence to 
transmit a note to the MD to switch it into whatever the blank 
pattern is (which is, of course, associated with the correct kit), so 
that I don't have to worry about remembering what settings I need.

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

Once upon a time, daniel_elektron wrote:

d> I hope that the explanation above gives you a better idea of why we
d> say it is "impossible" to allow the locks to be transmitted by MIDI,
d> even though it could work acceptably in certain limited situations!

Yes, this is perfectly described.  Thank you very much for the
detailed explanation, Daniel - it is as I expected...  and it now
makes complete sense.



-- 
Best regards,
Adam Watson

soundwithin
www.soundwithin.net

Thanks for the information Daniel - I appreciate your arguments, 
especially given the fact that you included numbers concerning the 
MIDI standard that I myself am not familiar with.

I still think that you could send CC's between 'note on' events.  
There is plenty of room between notes - at 120 BPM, there is 500 ms 
between note triggers - you could stick close to 500 CC's in there 
and never miss a beat.  Even at higher BPM - 180 for example, you 
could throw ~ 300 CC events between triggers.  I have never recorded 
this many paramter locks in a pattern - I think it must be rare that 
somebody does.  

If you were to go through all of the preset patterns that the MD 
ships with, I'm guessing that they would all play back nearly 
identically if you could record them with CC events placed in between 
notes.  I think that dropping CC's would be very rare.  Having 360 
parameter locks per step (or whatever the number is) is overkill for 
most music.  If I'm wrong, then point me at some mp3's that required 
this degree of control.  I'm glad to have that many locks - don't get 
me wrong - but I'd be happier if I could also export patterns with 
lock values to cubase.

I would also be happy to give up smooth sweeps in order to be able to 
record the parameter locks.  If I write a pattern that requires 
smooth sweeps, then I have no problem using the MD's internal 
sequencer to achieve this end.

Anyway - I really dig the MD, and I really appreciate the support 
(the new OS addresses just about every complaint aired in this forum, 
and adds a bunch of functionality as well).  How much room is left in 
the EPROM for additional upgrades?  Two things I'd like to see are a 
graphical representation of the dynamix compression curve, and a 16 x 
16 square grid representation of a pattern (like some drum machines 
have).

Keep up the excellent work.

-gerald

> 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

I am considering the other way : External Sequencer -> MD

Wouldn't the CC you suggest to be sent between notes affect the 
sound ? I may think wrong but my point is that incoming CCs are 
processed as soon as received. If so it becomes clear that a change 
in the pitch or filter settings would change the sound realtime.

I know that you are suggesting a solution enabling the MD to "spit 
out" its parameter locks but it seems to me that the usual thing is 
that a sequence recorded from an instrument by an external sequencer 
should give the same results when being replayed with the same 
instrument from the exernal sequencer. If I understand you correctly, 
that would not work.

However, that could be a feature of the MD with a cryptic name 
like "asynchronous play" or anything you'd like :)

I hope I haven't been too cryptic myself.

Xavier

--- In elektron-users@y..., "oldmanfury" <erinys@s...> wrote:
> Thanks for the information Daniel - I appreciate your arguments, 
> especially given the fact that you included numbers concerning the 
> MIDI standard that I myself am not familiar with.
> 
> I still think that you could send CC's between 'note on' events.  
> There is plenty of room between notes - at 120 BPM, there is 500 ms 
> between note triggers - you could stick close to 500 CC's in there 
> and never miss a beat.  Even at higher BPM - 180 for example, you 
> could throw ~ 300 CC events between triggers.  I have never 
recorded 
> this many paramter locks in a pattern - I think it must be rare 
that 
> somebody does.  
> 
> If you were to go through all of the preset patterns that the MD 
> ships with, I'm guessing that they would all play back nearly 
> identically if you could record them with CC events placed in 
between 
> notes.  I think that dropping CC's would be very rare.  Having 360 
> parameter locks per step (or whatever the number is) is overkill 
for 
> most music.  If I'm wrong, then point me at some mp3's that 
required 
> this degree of control.  I'm glad to have that many locks - don't 
get 
> me wrong - but I'd be happier if I could also export patterns with 
> lock values to cubase.
> 
> I would also be happy to give up smooth sweeps in order to be able 
to 
> record the parameter locks.  If I write a pattern that requires 
> smooth sweeps, then I have no problem using the MD's internal 
> sequencer to achieve this end.
> 
> Anyway - I really dig the MD, and I really appreciate the support 
> (the new OS addresses just about every complaint aired in this 
forum, 
> and adds a bunch of functionality as well).  How much room is left 
in 
> the EPROM for additional upgrades?  Two things I'd like to see are 
a 
> graphical representation of the dynamix compression curve, and a 16 
x 
> 16 square grid representation of a pattern (like some drum machines 
> have).
> 
> Keep up the excellent work.
> 
> -gerald
> 
> > 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

--- In elektron-users@y..., "oldmanfury" <erinys@s...> wrote:

> I still think that you could send CC's between 'note on' events.  
> There is plenty of room between notes - at 120 BPM, there is 500 
> ms between note triggers - you could stick close to 500 CC's in
> there and never miss a beat.  Even at higher BPM - 180 for
> example, you could throw ~ 300 CC events between triggers.

Where do you get your numbers from?

If we go for the worst case: (We need to design for worst case always
in order to make it reliable)

300bpm, 1/32 notes

1/300 minutes per beat
(1/300)*60=0.2 seconds per beat
0.2/32 = 6.25 ms between two trigs.

In 6.25 ms you could stick more or less 1 note on plus six CC's. And
they're spread out in the time slot between the two trigs. My opinion
is that it is better not to send out trigs than to limit the lock
count to six per step and give up smooth external editing.

> Anyway - I really dig the MD, and I really appreciate the support 
> (the new OS addresses just about every complaint aired in this
> forum, and adds a bunch of functionality as well).  How much room
> is left in the EPROM for additional upgrades?

We're using Flash, and the space is currently not really a problem.

> Two things I'd like to see are a graphical representation of the
> dynamix compression curve,

I agree on this one. The problem is that the Dynamix is not really
the key feature, and that's why this has not been prioritised so far.

> and a 16 x 16 square grid representation of a pattern (like some
> drum machines have).

...this is not planned...

Best regards,

Daniel Hansson, Elektron

On Fri Oct 11 2002, daniel_elektron <daniel@...> wrote:

> I agree on this one. The problem is that the Dynamix is not really
> the key feature, and that's why this has not been prioritised so far.

It might not be the key feature, but hey, it rocks! :)

What I would like is to NOT send certain sounds through the compressor
(without using the individual oute). Some sounds I prefer clean, some
sounds should be compressed to hell and back!

Oh well, I'll have to upgrade to 1.12 soon, but not today. Tonight me
and a couple of friends are playing live, and the MD is my main
sequencer...

If you live in G\ufffdteborg, Sweden, drop by tonight. No entrance fee. See
http://www.average.dk/kulturnatta for more details.

/Janne

-- 
Janne G:son Berg, d3berg@...   http://www.dtek.chalmers.se/~d3berg
                                      .

I hope music won't be ruled one day by mathematics... Brrrrr... =: D
But actually underground... In a certain form, it is... Na???

Moreno

> -----Original Message-----
> From: daniel_elektron [mailto:daniel@...]
> Sent: Friday, October 11, 2002 10:14 AM
> To: elektron-users@yahoogroups.com
> Subject: [elektron] Re: recording the locks one last time
> 
> 
> --- In elektron-users@y..., "oldmanfury" <erinys@s...> wrote:
> 
> > I still think that you could send CC's between 'note on' events.  
> > There is plenty of room between notes - at 120 BPM, there is 500 
> > ms between note triggers - you could stick close to 500 CC's in
> > there and never miss a beat.  Even at higher BPM - 180 for
> > example, you could throw ~ 300 CC events between triggers.
> 
> Where do you get your numbers from?
> 
> If we go for the worst case: (We need to design for worst case always
> in order to make it reliable)
> 
> 300bpm, 1/32 notes
> 
> 1/300 minutes per beat
> (1/300)*60=0.2 seconds per beat
> 0.2/32 = 6.25 ms between two trigs.
> 
> In 6.25 ms you could stick more or less 1 note on plus six CC's. And
> they're spread out in the time slot between the two trigs. My opinion
> is that it is better not to send out trigs than to limit the lock
> count to six per step and give up smooth external editing.
> 
> > Anyway - I really dig the MD, and I really appreciate the support 
> > (the new OS addresses just about every complaint aired in this
> > forum, and adds a bunch of functionality as well).  How much room
> > is left in the EPROM for additional upgrades?
> 
> We're using Flash, and the space is currently not really a problem.
> 
> > Two things I'd like to see are a graphical representation of the
> > dynamix compression curve,
> 
> I agree on this one. The problem is that the Dynamix is not really
> the key feature, and that's why this has not been prioritised so far.
> 
> > and a 16 x 16 square grid representation of a pattern (like some
> > drum machines have).
> 
> ...this is not planned...
> Best regards,
> Daniel Hansson, Elektron

Oh, but all music is math.  It's an idea I have meen thinking about 
for a long time.  Math is a part of human nature.  We got ten 
fingers, first computer?, preference for the metric system around the 
world.  Notes are a mathematical relationship of each other with the 
usual A being 440 khz? as the beginning standard for tuning a piano.  
But this can vary as with eastern music and it's still mathematical.  
But it starts in math.  It's a mathematical representation of sound.  
And I think math is flawed, but thats another story.  Why doesn't 
your dog start dancing or bobbing it's head?  Is it cuz the notes 
don't add up in it's head?  And the spiritual side of music?  Well 
that's not math.  Still human nature.  You don't see your dog going 
to church or mosque or temple or whatever they call jewish places of 
worship, do you?  What do they call jewish places of worship?  
Releave my ignorance.  

> I hope music won't be ruled one day by mathematics... Brrrrr... =: D
> But actually underground... In a certain form, it is... Na???
> 
> Moreno

On Sat, Oct 12, 2002 at 07:39:37AM -0000, endlessnessisticman wrote:
> Oh, but all music is math.  It's an idea I have meen thinking about 
> for a long time.  

try thinking about this...math is an ideal model.  It can only
represent music to some degree of accuracy.  So, much of music
can be described with math, but there is more to it. :)


> Math is a part of human nature.  

Math is a specialized system of symbol manipulation, which,
as you point out below, is quite unique to humans!!!  if you
want to read more about this, I *highly* recommend 
_Lanugage in Thought and Action_ by Hayakawa.  Worth its weight
in MIDI cables.



> We got ten 
> fingers, first computer?, 

another one of the first computers was----little rocks!  
That's how people counted---moving rocks from one pocket to
another to represent animals.  And that's where the word
"calculus" comes from---it's latin for "pebble."  
(I learned that from the above book- I'm telling you it's great!)



> preference for the metric system around the 
> world.  Notes are a mathematical relationship of each other with the 
> usual A being 440 khz? as the beginning standard for tuning a piano.  

...standard inthe U.s.!  other countries its different!


> But this can vary as with eastern music and it's still mathematical.  

Yes, most musical scales, despite ahving different numbers of steps,
or varying degrees of perfectness in representing their intervals,
are STILL equally spaced in the exponential scale. 



> But it starts in math.  It's a mathematical representation of sound.  
> And I think math is flawed, but thats another story.  Why doesn't 
> your dog start dancing or bobbing it's head? 

Another book I HIGHLY recommend is _Music, the Brain and Ecstacy_.
(not the drug...)  it's LARGELY about perception of music, and
composing.  absolutely fascinating.  



>  Is it cuz the notes 
> don't add up in it's head?  And the spiritual side of music?  Well 
> that's not math.  Still human nature.  You don't see your dog going 
> to church or mosque or temple or whatever they call jewish places of 
> worship, do you?  What do they call jewish places of worship?  
> Releave my ignorance.  

(temples).  Dogs experience community in other ways, I guess.  They're
so much simpler (and content!!!)


> > I hope music won't be ruled one day by mathematics... Brrrrr... =: D

suposedly the new autechre album is :)



-- 
                                 DSP Audio Effects! http://gweep.net/~shifty
     .        .       .      .     .    .   .  . ... .  .   .    .     .      .
"La la la laaa laaa laaa                   "      |     Niente 
 La la la laaa laaa laaa."  -Stereolab            | shifty@...

Do you know if anyone who is working on a remore programming tool for 
the MD? I could sure use one because I'm not happy with the tools in 
the device.

Thanx,
Niels.

--- In elektron-users@yahoogroups.com, Adam Watson <adam@s...> wrote:
> Once upon a time, Mind wrote:
> 
> MM>   NRPNs use up less MIDI data than CCs?
> 
> Actually, no... in rereading my post, my statement was just a little
> unclear. Sorry about that. What I was intending to get at was that 
by
> using NRPNs, all control change information could be processed by 
only
> using a defined set of CCs on a single MIDI channel, versus 
filtering
> and processing CCs across 4 MIDI channels. I probably should have 
used

> a more appropriate term like "processing bandwidth" versus
> "traffic"...
> 
> On the other side of the coin, I do appreciate Elektron using only
> CCs, as this makes programming utilities or creating editors for the
> unit much more straightforward than having to deal with NRPNs.
> 
> Still wonder what the real reason for not being able to record
> Parameter Locks is, though...
> 
> 
> 
> -- 
> Best regards,
> Adam Watson
> 
> soundwithin
> www.soundwithin.net