Author |
Message |
duracell
Joined: Sep 06, 2004 Posts: 28 Location: lyon, france
G2 patch files: 2
|
Posted: Sat Oct 16, 2004 5:58 pm Post subject:
sending midi between slots |
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24081 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Sat Oct 16, 2004 6:53 pm Post subject:
|
|
|
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
|
|
|
duracell
Joined: Sep 06, 2004 Posts: 28 Location: lyon, france
G2 patch files: 2
|
Posted: Sat Oct 16, 2004 7:52 pm Post subject:
|
|
|
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
|
|
|
jksuperstar
Joined: Aug 20, 2004 Posts: 2503 Location: Denver
Audio files: 1
G2 patch files: 18
|
Posted: Sat Oct 16, 2004 8:03 pm Post subject:
|
|
|
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
|
|
|
egw
Stream Operator
Joined: Feb 01, 2003 Posts: 1569 Location: Asheville NC
Audio files: 18
G2 patch files: 8
|
Posted: Sun Oct 17, 2004 5:34 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24081 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Sun Oct 17, 2004 6:24 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24081 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
|
Back to top
|
|
|
|