delicate bending

[dr bu]

who thinks 127 is a good range for a gissando? whitch vstis got 14 bit pitchbend? and if you have to do it sysex, where is the easy to use compiler?

[GaryN]

I assume you're referring to 127 as half of a 256-bit pitchbend range using 8 bits.
127 is not a range but rather the resolution.

If the maximum bend range is defined as 1 step (1/2 sharp or flat) the resolution is 1/2 step ÷ 127 which, if resolved properly by the plugin or whatever should be pretty darn "delicate".

14-bit bend would be ludicrous overkill… but you probably already know that.

[dr bu]

thats right "resolution" - not range. pitchbend-range is of course expressed in semitones.
 
ok, so pitchbend is sent to the vsti or a hardware synth via so called MSB and LSB (most and least significant bytes) sysex messages. most synths only read the pitchbend-MSB so the resolution is then 127. some can read LSB as well an viola! resolution becomes 16384 or 14 bit. now 127 may seem like a high enough number but lets say you want to carry out a glissando over 12 semitones. i often feel like it. this is not uncommon for a voice or violin. you will then end up with an ear training exercise, not a smooth glissando. on some synths the pitchbend-range can be set to 36 semitones or 3 octaves, maybe more. you will then be looking for some LSB.
or what if you are into exotic tunings. a 127 resolution is not sufficient when you want to play your JV-1010 like LaMonte Young.
the midi-implementation-chart will tell you how to change the resolution, if possible, but it has to be done in Hex. its tedious!
 
anyway, i was thinking maybe someone had walked this path before me.

[GaryN]

You're analysis of pitchbend is pretty accurate. The issue is actually revealed in what you just posted. You're looking for a 12-semitone PORTAMENTO. That's not a pitchbend. Glissandos of the nature you describe are generated by triggering more that one note and the synth engine portamentoes (if there is such a word) from the 1st to the 2nd at a predetermined rate.

The resolution of that is determined internally rather that having to calculate and respond to a constantly varying external control signal.

I'm sure others have "walked this path before you". I suspect they have better success with actual analog hardware (no MSB LSB issues at all that way) and they probably don't try to play a JV-1010 (or most other mass-produced MIDI synths) that way.

I think you're wanting the MIDI 1.0 spec to perform like some future 5.0 spec that's not here yet.  The reason that pitchbend spec only carries 8 bits is because it's a spec. As such, it's designed as a careful compromise between ultimate performance and practical implementation across an entire industry that includes instruments ranging from $50,000 all the way down to $79.95.

The data density of a theoretical 14-bit pitchbend stream is well beyond the capacity of the control paths and circuits involved. It's also probably well beyond the resolution of what you actually need (I'm thinking 10 bits) to get the "smoothness" you want anyway.
 
At the end of the day, you're wishing for something that doesn't exist. Nothing wrong with that at all, that's how things improve.

[dr bu]

ok thanks Gary. but we are clearly getting our wires crossed here 
http://www.midikits.net/midi_analyser/pitch_bend.htm
http://en.wikipedia.org/wiki/MIDI_controller#Use_in_a_data_stream

relevant as my questions seems to me, maybe noone at this forum uses pitchbend 

[widdly]

All of the synths I know respond to the full resolution  14bit pitchbend.  What synth only uses the MSB of pitchbend messages?  I wonder if you are sending the messages properly.

I like a +/- 1 octave bend range which would be VERY stepped with a 7 bit bend resolution.

[dr bu]

Right! I dont know how i missed that Thanks!

I like a +/- 1 octave bend range which would be VERY stepped with a 7 bit bend resolution.

Good for you 

[GaryN]

OK. I apologize for my lack of clarity…it was late.
The point I'm ultimately trying to make is: Although the pitchbend spec provides two bytes per message to provide 16-odd thousand discrete steps, can you actually ever get that in a practical way?

Example:
I go into my sequencer and graphically draw a loong, straight PB line over enough measures to assure max visible resolution. I then look at those messages in a list and they are indeed, although not precisely 1-bit increments (more like 2 or 3 but close enough) I do now actually have a long string of 14-bit PB commands showing - lots and lots of them.

However…
Try as I might I cannot generate massages like that from any controller I have (admittedly, NOT $10k keyboards, but good common Yamaha & Roland stuff). The best I can get is 127 (rounded to 130) bit steps.
The controllers simply refuse to resolve and send anything finer that that.
I can actually push a PB wheel very slowly and see the message output blink on my Studio 5 each time a PB message is generated.
No settings, adjustments, hammer-smashing I can do will cause a finer, thicker, higher resolution of pitchbend data to be output and sent.

This is what I was so poorly trying to say yesterday… Although the controllers do send 14-bit numbers, they don't send enough of them. Rather, they seem to send no more than they would in an 8-bit mode.
Actually, the numbers they do send, seem to very much correspond to 14 bits quantized down to 8.
I believe this is simply because if they did, you'd have a good chance of choking an entire sequenced MIDI stream every time you implemented a bend unless there were NO other instruments / data in the sequence. None of this applies to a self-contained instrument of course, where the relationship between engine and controller can be as precise as the designer wants. But, we're talking about controllers, synths, VSTi's and such here that communicate via the MIDI stream. So, although the resolution is in the spec, I don't see it actually being implemented effectively in practice. It seems to be just another one of those things they consider to be a fringe situation that you get to go in and edit / improve after recording if necessary.

God knows, my name is NOT Oppenheim and there's a whole helluva lot I don't know about the tiny details of electronic musical hardware and software, but this is my experience. If I'm out to lunch here, I'd love to have somebody educate me a little. I'm not yet too old to learn something…

[IIO]

I assume you're referring to 127 as half of a 256-bit pitchbend range using 8 bits.
127 is not a range but rather the resolution.

hm, yeah, he mixed up range and resolution, but if we start like that then i would like to point out that a 256-bit pitchbend also does not exist.

nor does 8-bits play a role here.

or 7.

nothing of that exists.

pitchbend always was using 14 bit numbers made out of two 7 bit words.

14-bit bend would be ludicrous overkill… but you probably already know that.

and i wholeheartly (or however that word is supposed to be written) disagree that 8 bits over 7 bits is a sufficient solution for pitch bend.

for "bend" maybe - because most signal generators would interpolate the parameter input anyway - and the parameter input has a very low time rate - but not for "pitch".

you probably know that some people are using the pitch bend controller to do microtuning with devices which dont support it in another way. for tuning frequencies for music 32 bit floating point would be nice - and 64 bits would be what you´d like to have.

[IIO]

...

[GaryN]

I assume you're referring to 127 as half of a 256-bit pitchbend range using 8 bits.
127 is not a range but rather the resolution.

hm, yeah, he mixed up range and resolution, but if we start like that then i would like to point out that a 256-bit pitchbend also does not exist.

nor does 8-bits play a role here.

or 7.

nothing of that exists.

pitchbend always was using 14 bit numbers made out of two 7 bit words.

14-bit bend would be ludicrous overkill… but you probably already know that.

and i wholeheartly (or however that word is supposed to be written) disagree that 8 bits over 7 bits is a sufficient solution for pitch bend.

for "bend" maybe - because most signal generators would interpolate the parameter input anyway - and the parameter input has a very low time rate - but not for "pitch".

you probably know that some people are using the pitch bend controller to do microtuning with devices which dont support it in another way. for tuning frequencies for music 32 bit floating point would be nice - and 64 bits would be what you´d like to have.

I gotta admit llO, as is so often the case, I have NO friggin' idea what you're talking about, but i think it is not what I'm talking about.

Dr bu was wanting 14-bit pitchbend. I was pointing out that I can't get a controller to generate anything finer in 14-bit than one could get if the bend spec was 8-bit. The damn things send big 14-bit numbers but skip so many that having 14-bit numbers is a waste of data.

We all know there's no such thing as 256-bit pitchbend. 256 is the maximum number generated with 8 bits. (as -127,0,127)

The MIDI spec for pitchbend is 14 bits for 16384 maximum. (as -8192,0,8192)

The reality however, seems to be that all that is commonly generated, transmitted, resolved and acted upon is the equivalent resolution you could get with just 8 bits.

[dr bu]

in Max we have one object: bendout~, for 7-bit and another: xbendout~, for 14-bit. the difference between them is obvious to any ear.
since this is programming and not wheelbending i can with the latter oject sit on any of 16384 steps, which is delicate enough for my needs.
and yes, as can be examined in a listeditor, 7-bit pichbend is actually 14 (LSB is always zero).

[IIO]

I gotta admit llO, as is so often the case, I have NO friggin' idea what you're talking about, but i think it is not what I'm talking about.

...

The reality however, seems to be that all that is commonly generated, transmitted, resolved and acted upon is the equivalent resolution you could get with just 8 bits.

the reality often seems to be quite different from what we think how it is.

hardware controllers are only one of many options how to generate data, and in conjuntion with software plug-ins the relevance to software-generated controller data is raising from year to year.

the fact that most hardware controllers would not allow to produce data of a higher range or precision than what 7 or 8 bit offers does not automatically mean that 7 or 8 bits is sufficient for tuning audio material for music.

as someone already pointed out, you might want to use up to 1 or 2 octaves for a "pitch bend controller", and if you do so, you wil be happy to have the full 14 bit range, or even floating point at your hands.

since bu is using host applications such as max/msp, it will be normal for him to generate 32 bit data - and that is why it is a pity that most vst plug-ins only support some form of virtual midi with the usual shit resolution of midi.

unless you are using logic audio, you will control plug-ins with 32 bits data anyway as soon as you access the VST parameters directly.

and there are various usb controllers which can send up to 10 bits, and there are network protocols which support whatever you want, too...

[GaryN]

And as usual, we now come to that familiar crossroads where performance and programming meet and then diverge. Where your inspiration takes you outside of the "norms" and so you have to find a way to create / generate / program what you hear in your head to force your non-compliant mediocre hardware into reproducing your artistic vision.

Some of us will take the path less trodden and gradually become number-crunching, bit-tweaking, precision seeking tech / musician hybrids seeking a way to get that subtle little "thing" we desire to actually happen despite the lack of commercial product available to help.

Some of us will just say "Fuck it" and write the damn song.

[IIO]

it is an interesting question if those who stopped using what the market gave us as "norms" and asked for more or migrated further are somehow more progressive or if they are just to dumb to properly use a modwheel.

in my case you would be right; i haven´t played live for 20 years and i am not even producing anymore, instead i am working on a totally different field.

but it is not like noone would be using 10 or 12 bit controller hardware or programming language scripts in a live situation.

in my opinion there is always at least two branches or (different forms?) of "technological progress", one of which i would agreee with you that you dont need it for productivity or fun.

most professional players of medieval crooked horns will ask you why you are using keyboards with mod wheels instead of just playing the danmed song, too, these things are always a matter of perspective.

[GaryN]

Amen

[dr bu]

I gotta admit llO, as is so often the case, I have NO friggin' idea what you're talking about, but i think it is not what I'm talking about.

Amen

[dr bu]

in Max (still 4.1 ofcourse), is it possible to send sysex-data to the vst~ object?
i think not.
according to the manual a vst~ oriented midievent-message is supposed to be followed by 2-4 numbers.
the first 2-3 numbers happily send regular note and control-messages.
(the fourth number is a 7-bit pitchbend-message which doesnt seem to be implemented correctly btw)
anyway, importing a midifile containing sysex into the seq-object i notice (textview) it splits the array into chunks of 4!
thats why i came up with this idea 
(in re-saving, this data get lost.. seq:s midi-textformat seems to be max-only)
i had a look at cycling 74s forum about this, no luck...

[IIO]

note that "midievent message" is already something totally different than MIDI in max.

where you would send "midievent 144 64 60" to [vst~] you would send something like "x90 x3C x40" to a midi device.

so nope, there is no midi-in at all in the vst object, even when there is a midi implementation in the plug-in. instead you can send a quasi vst controller data to all parameters of the plug-in (which you cant do in cubase and protools)

"midievent" only handles note on and note off (and fake-"all notes off") properly, i wouldnt use it for controller messages at all.

incoming midi data should be caught by [midiin] and formatted properly by yourself - exactly the way you want it to work.

the fourth argument, btw, is note number microtuning, not wheel, and to my knowledge there is no VST plug-in on OS9 which would support it (eventually native instruments stuff, havent testet those, but otherwise midi microtuning in vst~ is a windows OS thing.)

in my opinion it is far easier to check the the plug-ins architecture by the "get" messages to vst~ and then convert incoming MIDI to vst controller data: "5 0.7"

have you worked with the "get" stuff yet? i have made a nice overview once, will see if i find it.

in addition it can also be "better" because it raises the controller resolution from 7 to 32 bit, so that you are for example able to interpolate the incoming data from a hardware controller - or set it to an exact value of your choice.

[IIO]

sysex isnt supported at all, not from the host, not from plugins. there are for sure better ways to do what you want.

to come back to your original question i would also like to suggest to create such a synthesizer right in max/msp or use VST plug-ins which have a good internal glissando/portamento effect (there are plenty)