electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
sending midi between slots
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [7 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
duracell



Joined: Sep 06, 2004
Posts: 28
Location: lyon, france
G2 patch files: 2

PostPosted: Sat Oct 16, 2004 5:58 pm    Post subject: sending midi between slots Reply with quote  Mark this post and the followings unread

so I was working on some patches with some complicated triggering, lots of counters and sequencers, full of logic stuff, and to free up some dsp power I thought well why not just send the processed data into another slot over a midi controller. this way one slot processes all the data using 100% of the patch and the 20 interesting control signals are sent via 20 controller outs to patch B for example. now in patch B only 20 controller ins are needed and there is loads of dsp% left.

eureka! this worked!

BUT,

some things were dropping out. I was using triggers on my drums, and the trigger needs a mask time (pulse length) otherwise you get double triggers, this seems to vary from 15 to 50 ms depending on drum type: a snare and floor tom have totally different envelopes, dynamics, and desired dynamic range. all the sequencers depend on this pulse, but if you send that pulse over a midi controller from one slot to another well that pulse probably will come through the other end but not for sure.

it seems that the longer the pulse the more chances it will come out the other end. and I got no misses with longer pulses ( >100ms IIRC). unfortunately the lowest pulse time with nearly no misses was too big meaning the drums weren't responsive enough.

so it seems that midi between slots is ok for slow information, like really slow, how slow exactly? I'm not with my modular right now, but if I was I'd try sending some audio this way! hmm no that wouldn't work, I'm understanding this as I'm writing: I don't have a clue about midi bandwidth!

could the G2 oversample the midi or am I out of my depth here?!

-----------------
[dream]I wish my G2 was just one big huge 800% patch (1600% expanded)[/dream]
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24081
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sat Oct 16, 2004 6:53 pm    Post subject: Reply with quote  Mark this post and the followings unread

So you hit the internal midi bandwidth limit, interesting ... Please post the patch !!

There is something you can do about it, probably, assuming you don't neeed the full rate for all the controller data you send. I usally don't ...

You could slow some of the signals by issuing sample and holds before the midi sends & clock those with some sensible, preferably slow, clock to reduce the data rate for such controller sends.

Slowing down some signals will give room for others to go faster, that's the idea.

Another way to go would be to send over wider pulses (so they won't be skipped) and limit the puls width at the receiving end instead, but timing might get a bit loose then.

And when you like jig saws ... try to not send midi signals that the teceiver could easily compute from other midi signals, that is try to remove the redundancy. This requires a certain mind set / training, but it works best probably.

You seem to have a somewhat fasr computer, over here the editor usually gets too slow before I hit the bandwith limit (although I must say things are improving with later version numbers).

BTW, I like your dream, although there are ways to live with the current limitations.

& Don't know if you know it, but a great help to reduce DSP load is to make some red signals blue by inserting a note quantizer set to default values in red chains, it's really a great DSP saver for some patches.

Jan.
Back to top
View user's profile Send private message Visit poster's website
duracell



Joined: Sep 06, 2004
Posts: 28
Location: lyon, france
G2 patch files: 2

PostPosted: Sat Oct 16, 2004 7:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

searching for information on midi bandwidth I found this

Quote:
The MIDI bandwith (i.e. transmission speed) is 31,250 bits per second (BPS). Therefore, because there are 10-bits in every MIDI "byte" (consisting of 1 start bit, 8 data bits, and 1 stop bit), the actual bytes which can be transmitted per second is 3,125. That converts to a delay between each byte of (1/3125) .00032 seconds or .32ms (milliseconds).


here: http://midistudio.com/Management/R-Finley/q&a.htm

and this

Quote:
Well, it takes 960 microseconds to send each note, so by the time that the 5 piano notes are sent, it's already 4800 microseconds later than the downbeat. By the time that the bass note gets sent, it's 7680 microseconds later than the downbeat when it was supposed to sound.


here: http://www.borg.com/~jglatt/tutr/midibus.htm

that sounds fast enough. I need to do some more extensive tests, I couldn't spend time on this because I had a deadline for a live show. btw YOU taught me the note quantizer trick last time jan and it saved my ass!

or maybe using the internal busses there are ways of increasing the number of busses by downsampling say have 16 busses at 16khz sample rate, with some clever clock mechanism. IIRC there was some talk about increasing delays using a system like this (can't find link)
Back to top
View user's profile Send private message Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Sat Oct 16, 2004 8:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

The "MIDI" rate is limited to those figures due to physical limitations (serial connection, etc). Internal to the Nord, however, that shouldn't apply. The Nord could be using almost any rate to transfer MIDI data internally, and it might not even be "MIDI".

Some test patch might find the answer. No time now, but I'll think about it after the weekend.

Jan is right about the S&H modules, however. If the int. midi is hitting it's limit, that should help a great deal.
Back to top
View user's profile Send private message Visit poster's website
egw
Stream Operator


Joined: Feb 01, 2003
Posts: 1569
Location: Asheville NC
Audio files: 18
G2 patch files: 8

PostPosted: Sun Oct 17, 2004 5:34 am    Post subject: Reply with quote  Mark this post and the followings unread

I've noticed some lag when sending midi volume (using a knob) from one slot to another. The lag appears on the leds too, so it must be happening locally, or at least is being detected locally.
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24081
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Oct 17, 2004 6:24 am    Post subject: Reply with quote  Mark this post and the followings unread

duracell wrote:
that sounds fast enough. I need to do some more extensive tests, I couldn't spend time on this because I had a deadline for a live show. btw YOU taught me the note quantizer trick last time jan and it saved my ass!


Sorry I forgot your name, I'm not too good at remebering names but I'm sure I'll manage to remember it better now :-)

The about 1/3 th of a mili second peer byte in the other example is correct (and a controller message is three bytes (or about 1 ms as in the piano example) or two when it can be encoded using running status).

But this is for MIDI over a physical MIDI cable, the internal bandwidth in the G2 is much higher but unspecified. Still it could be easy to hit the bandwidth limit as the blue signals may be slow compared to red signals they are not _that_ slow of course.

Using S&H's to slow down things is a form of downsampling.

When you want to send multiple signals over one internal bus that indeed is possible by using some multiplexing and demultiplexing and this has been discussed somewhere indeed I think, either overhere or on the NM list. I'll see if I can find it back, if so I'll let you know.

Jan.
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24081
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Oct 17, 2004 10:37 am    Post subject: Reply with quote  Mark this post and the followings unread

Ok, I couldn't find anything about the multiplexing trick so I made an example patch for it.

Variation 1 .. 8 will enable more and more oscillators in the FX area.

I used multiplexing on the FX bus, but this should work the same on the other busses.

Jan.


multplex.pch2
 Description:
Example patch for slot multiplexing

Download
 Filename:  multplex.pch2
 Filesize:  2.98 KB
 Downloaded:  2282 Time(s)

Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [7 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use