VSTI world hate MIDI GUITAR?

[AdmiralQuality]

You can always just simply "split" a polyphonic performance on a single channel to get different sounds from different parts of the note range... that's how keyboard players do it... but again, you're losing out on part of the guitar if you do it that way.

But even with guitar in Mono mode, you can still split sounds not just on a per-string basis, but on a given fret on a given string as well. This is relatively easy to set up in most hosts.

[Sascha Franck]

So what things are several mono modes good for besides per string pitch bend. The only thing I can think of is having a different synth patch per sting! that would be wild.

For example, sometimes I make the guitar into a "brass section" or "string section" by assigning different brass or string instruments to the different strings, more or less according to their natural range. Play a chord and it sounds a heck of a lot more natural than mashing a chord on a "brass" or "strings" patch on a keyboard. One has to be careful constructing melody lines with such a setup, however.

Tip: Try some "drop 2" chords (close voicings with the second note from the top dropped an octave, those work all well on guitars) on the top 4 strings. Assign trumpet = E1, alto = B2, tenor = G3 and trombone = D4.
Perfect setup for some jazz/funk/pop compings.

[funkadil]

That very good information to know. Thanks!

[nikp2000]

_

Really good to see midi guitar getting some attention.

According to the gr20 manual:

In order to convey the beginning of a note as quickly as possible, and to allow the pitch to change flexibly, the gr20 transmits the pitch as a combination of note messages and pitch bend messages.

So if your intonation or tuning is off, or if you bend the string a bit as you pick it, you may get the wrong pitch or a glitch. Clean picking and not accidentally triggering other strings is the key.

Inspired by this thread I went back and set up several racks in Tracktion (you could do the same using ext) using the free ndc midi plugs to split the channels and my tracking was way better than I remebered. Depending on the note range you need, you can just use the top 2, 3 or 4 strings and avoid triggering bass notes with the heel of your hand. Still, buckets of midi cc data is generated and needs to be thinned.

Nick

_

[AdmiralQuality]

Still, buckets of midi cc data is generated and needs to be thinned.

Nick

_

If that IS the case, then you need to thin it FROM the GR-20 itself. Because once it's in the MIDI Cable, the delay is already there.

If you're inserting something to do "thinning" downstream of the GR-20 itself, whether hardware or software, it's not going to help one bit... as any messages are already held up by the time they get to it.

The synthesizer software in your computer is NOT having delays caused by any MIDI traffic, as even a saturated MIDI cable represents only the tiniest trickle of data to your computer, absolutely nothing compared to even one channel of digital audio.

Does the GR-20 have thinning functions itself? (Checks manual....) Nope... not that I see. So don't worry about "thinning", you can't thin after the fact... you can't make a late event become on time (if indeed there are any substantially late events, I'd think the GR-20 itself would prioritize note-ons over controller data anyway) as there is no time-stamp data in a MIDI stream. Events happen when they are received.



(GI-20 owners however can rejoice in the fact that they can connect with a USB cable instead of a MIDI cable, so they shouldn't experience any delays at all -- at least none caused by MIDI stream congestion -- as the bandwidth of USB 1.1 is far, far above that of MIDI. Remember, MIDI first appeared in 1983 and still has the exact same low bandwidth... but ONLY in a physical MIDI cable. Use USB, or MIDI messages internally in your host, and there are NO bandwidth issues to be had.)

[nikp2000]

_

If that IS the case, then you need to thin it FROM the GR-20 itself. Because once it's in the MIDI Cable, the delay is already there.

True, but I think the vstis glitch because of the amount of data they are receiving, especially if it contains spurious pitchbend and note info. As noted before, from the gr20 manual:

In order to convey the beginning of a note as quickly as possible, and to allow the pitch to change flexibly, the gr20 transmits the pitch as a combination of note messages and pitch bend messages.

Nick


_

[AdmiralQuality]

_

If that IS the case, then you need to thin it FROM the GR-20 itself. Because once it's in the MIDI Cable, the delay is already there.

True, but I think the vstis glitch because of the amount of data they are receiving, especially if it contains spurious pitchbend and note info. As noted before, from the gr20 manual:

In order to convey the beginning of a note as quickly as possible, and to allow the pitch to change flexibly, the gr20 transmits the pitch as a combination of note messages and pitch bend messages.

Nick


_

That's actually a GOOD-feature they're describing there Nick, not a caveat.

The idea is it sends the MIDI note-on before it's 100% sure exactly which note is is, because it can always use pitch bend an instant later to correct that note, without requiring another, second, note-on to be sent... which would create a glitch. So you might get the effect of a little bend at the beginning of notes, but hey, that's guitar!

Trust me, please. You can't thin data that's already in a MIDI cable (well, you COULD, but there'd be no point.) And your VSTis AREN'T being choked by too much controller data. Just does't happen.

You're using Mono mode, right? You have the pitch bend range of the GR-20 matching the bend range of your VSTis? You have reasonably low latency on your computer's audio interface?

Can you describe these glitches? Even better, could you SEND me a .mid file of some glitches so I can analyze it? You just might win my contest http://www.kvraudio.com/forum/viewtopic.php?t=147535 if you do.

[AdmiralQuality]

By the way, the whole data "thinning" concept comes from the other way around. The classic application of computers in music, back before you could actually crunch audio streams with them, you would use your computer purely as a sequencer to run EXTERNAL synths. You could process MIDI with even the oldest home computers (because MIDI data is so thin, ~30 kbps vs. ~12,000 kbps in a USB 1.1 cable!!!) Even an original IBM XT made a FINE MIDI sequencer -- and that's where products like Cakewalk originated... I used to use Cakewalk on a FLOPPY disk, on an IBM XT, with a Roland MPU-401 MIDI adaptor CARD.. back in the day. You couldn't record AUDIO with it, that was UNTHINKABLE! But it was a good sequencer with a nicer interface and monitor than some black box dedicated hardware solution with buttons and a tiny segmented LED read-out screen!

So, the issue back then was... your MPU-401 still only had one MIDI in and one MIDI out (or was it 2? Certainly no more than 2) So if you tried to daisy chain (or even use a splitter) to connect your one output to a LOT of synths, drum machines, etc, you'd be sending info for ALL of those instruments out the SAME MIDI port. Now normally the messages are pretty much instantaneous, but as MIDI is a serial interface, only one message can come out at once. So what happens if, say, at the start of a bar of your sequence 10 instruments play 5 note chords all at the exact same time? (which not a hard to imagine scenario!)

What happens is those 50 notes all have to get "in line", some will come out instantaneously, some will be delayed, and it's not hard for a good muscian to hear/feel the late ones. Let me see, at 31,250 bps * three 9 bit bytes (there's a stop bit) needed to send a MIDI note-on.... that's 27 bits * 50 notes / 31250 bps = 0.0432 sec = 43 ms before the last of our 50 simultanous notes comes out! (And that's the BEST case scenario, actual mileage will be worse.) If you've worked with a DAW, you'll know you can hear and feel a latency of 43 ms EASILY! (I start to feel it around 5 or 6 ms!) So that's where the concept of data thinning comes from; it was a strategy to keep the sequencer's outgoing bandwidth demands on the MIDI cable down (because controller messages also compete for these same spots in time as the notes... though there's actually no thinning approach to solve the 50 notes at once problem! )

Anyway, who plays 10 hardware synths anymore? So for us, going the OTHER WAY AROUND, it's just not a problem these days.

And like I said, if I was a Roland engineer (they should be so lucky! ) I would make sure that whatever controller data had to get out of the MIDI cable would be readily preempted by note-on events. So a note-on is NEVER held up waiting for a controller event (and I'm SURE they DO do this, it's a common technique to prioritize note-ons and offs.) As well, you can always toss a late controller event out entirely if there's a newer one of the same number on the same channel already ready to go. You just treat it as if it never happened so you can get the newer controller message out, ASAP.

So due to all that stuff, I really doubt that cable saturation is your problem. And even if it is, there's no way "thinning" it will help because your computer has ALL THE TIME IN THE WORLD to take care of MIDI data. It's slower than a slow modem! MIDI is easy. Audio is easy! It's HD video that's hard! (And even that, your computer can crunch pretty well... it's AMAZING the power we have on our desks compared to 1988! And again, MIDI wasn't a problem for computers to handle in '88, so I doubt it is now. )

[Sascha Franck]

I agree with AQ here, data thinning is pointless when it comes to the computer being able to handle it.
Makes sense on the controller though, at least once you know you're not going to play expressive solo lines. For chord work, I usually just switch the data thinning on my (rather mediocre, if at all...) GI-10 on and it's giving be quite better results in terms of less glitchy notes. I usually switch PB off as well, as I wouldn't need it for piano-ish sounds and the likes. Again, the incoming MIDI events are looking quite a bit better, no more PB events all over the place. Not that the PC would have problems dealing with them, but editing sometimes becomes quite a pain.

[arakula]

What happens is those 50 notes all have to get "in line", some will come out instantaneously, some will be delayed, and it's not hard for a good muscian to hear/feel the late ones. Let me see, at 31,250 bps * three 9 bit bytes (there's a stop bit) needed to send a MIDI note-on.... that's 27 bits * 50 notes / 31250 bps = 0.0432 sec = 43 ms before the last of our 50 simultanous notes comes out! (And that's the BEST case scenario, actual mileage will be worse.)

Ahem.
Cough.

First, MIDI has a start bit and a stop bit, so that makes 10.
Then, you didn't take Running Status into account. That is, the best case scenario is the transmission of 3 bytes + 49*2 bytes = 101 bytes (if we assume that RS already holds the correct status word, you can subtract another byte, but that's a difference in the sub-millisecond range). At 10 bits per byte, that's 1010 transmission bits / 31250 bps = 0.03232 sec = 32ms.

Which doesn't invalidate your argument, of course, since that is still very audible.

[AdmiralQuality]

What happens is those 50 notes all have to get "in line", some will come out instantaneously, some will be delayed, and it's not hard for a good muscian to hear/feel the late ones. Let me see, at 31,250 bps * three 9 bit bytes (there's a stop bit) needed to send a MIDI note-on.... that's 27 bits * 50 notes / 31250 bps = 0.0432 sec = 43 ms before the last of our 50 simultanous notes comes out! (And that's the BEST case scenario, actual mileage will be worse.)

Ahem.
Cough.

First, MIDI has a start bit and a stop bit, so that makes 10.
Then, you didn't take Running Status into account. That is, the best case scenario is the transmission of 3 bytes + 49*2 bytes = 101 bytes. At 10 bits per byte, that's 1010 transmission bits / 31250 bps = 0.03232 sec = 32ms.

Which doesn't invalidate your argument, of course, since that is still very audible.

As I said, that was a best case. Mr. Stickler! (Does MIDI have a start bit? Ah, yes it does. Sorry, I don't have to deal with it on-the-wire in code lately, so I tend to forget some of those harsh realities.)

Anyway, you're just making my point further (and thank you!)... events can traffic jam pretty easily on a MIDI cable.

(Um, wait a sec, isn't it 50 * 3 bytes? 3 = Status byte + and 2 data bytes (note num and velocity)? Or are you assuming running status with each channel's data sent perfectly together in series (which still wouldn't be 3 + 49*2... would it? Remember in my example we're talking to 10 different synths, presumably on different channels.)

And neither of us are taking into account that it's asynchronous, so you could have any arbitrary length of time between the bytes!

Anyway... heated agreement here I think.

'Nite.

[arakula]

You can only squeeze 10 synths' output through a single MIDI cable if you assume that they are all daisy-chained in a MIDI Out -> MIDI In fashion, or by using a MIDI patch bay. Assuming this, you can also assume that they all send on the same channel, in which case you'd need exactly 1 NOTE ON status word, followed by 50 note number/velocity pairs. That's where my "best case" scenario comes from. Assuming 10 different channels, the best case (i.e., MIDI messages sorted by channel) would be 10*3 + 40*2 bytes, giving 110 bytes, or 0.0352 second s = 35 milliseconds.

And I agree with your heated agreement

[Edit:] 'morning here

[AdmiralQuality]

You can only squeeze 10 synths' output through a single MIDI cable if you assume that they are all daisy-chained in a MIDI Out -> MIDI In fashion, or by using a MIDI patch bay. Assuming this, you can also assume that they all send on the same channel, in which case you'd need exactly 1 NOTE ON status word, followed by 50 note number/velocity pairs. That's where my "best case" scenario comes from. Assuming 10 different channels, the best case (i.e., MIDI messages sorted by channel) would be 10*3 + 40*2 bytes, giving 110 bytes, or 0.0352 second s = 35 milliseconds.

And I agree with your heated agreement

[Edit:] 'morning here

Um, no, you CAN squeeze as many as you want (up to 16 channels) on a single MIDI cable. And, as in my example, back in the OLD days, that's usually all we had coming out of our computer. And yes, daisy chained with THRU ports, or split with a patch bay, it's still coming from a single port so the issue is still there.

(Oh wait, do you think I'm talking about 10 controllers??? No, I'm talking about playback from a sequencer TO 10 hardware synths, on the same MIDI cable. And in 1988 you were lucky to have ONE MIDI out on your computer. It was NOT uncommon to set something like this up! Though you'd try to avoid too many notes going off at once, for these exact reasons.)

But the whole reason I picked that example was to demonstrate a case where data congestion IS an issue. I'm not trying to say it's a good idea to do this! It was just to contrast with a single MIDI *controller*, where data density is not QUITE so much of an issue, even for a guitar controller running 6 channels in Mono mode with PB on each channel. Just trying to explain what data thinning is (er, was) for. And why you can't do it to the output of your guitar synth controller (because that data is already on a MIDI cable! No point in thinning it!)

Anyway... "more heated agreement." 3:37 am here... time to pack it in. Ug! Nite2

[arakula]

Um, no, you CAN squeeze as many as you want (up to 16 channels) on a single MIDI cable.

Yep. I was thinking more of the other direction. Doesn't change my calculation, however.

And, as in my example, back in the OLD days, that's usually all we had coming out of our computer. And yes, daisy chained with THRU ports, or split with a patch bay, it's still coming from a single port so the issue is still there.

Yep, even worse - you had to use a patch bay or something like these nice little Phil Rees thingies to fan out the MIDI Thru signal, since a daisy chain of 9 MIDI Thru ports would distort the MIDI signal so much that only the first 3 or 4 synths would really be able to interpret it correctly (MIDI Thru is normally implemented by simply running the signal coming from MIDI In through an optocoupler, and off it goes again - after 3 or more passes, this ruins the nice, clean, sharp digital edges of the bits completely)...

Aaah, the "bad old days" .... I love my eMagic amt8/unitor8 cascade for this reason. Up to 64 physical MIDI ports accessible through 1 USB connection... all my MIDI devices have their own dedicated port. No Midi Thru hassle any more.

The only bad thing is that Apple in their infinite wisdom decided to kill off this product line completely. You can't even get OSX drivers for the x86-based Macs from Apple's "support" pages. Vista will presumably not be supported, either.

Anyway... "more heated agreement." 3:37 am here... time to pack it in. Ug! Nite2

'Nite.

[guitarzan]

Or...f**k all this guitar to MIDI shit altogether and use something that works like FrettedSynth's pitch to "CV" synths for mono lines. They track more expressively than pitch to MIDI ever will.

For polyphony, maybe run a hex pickup into one of those breakout boxes then into a 6 channel audio interface - then run the 6 channnels of audio into something like a multi-mono version pitch to "CV" synth, or 6 FrettedSynths in parallel if the system could handle it.

I really doubt MIDI is even capable of tracking the subtle dynamics and bends that the FrettedSynth pitch to CV type method can and does.

Just trying to think out of the box