Repurposed tech for VST control surfaces

[runagate]

The more I think of it, release velocity sensitivity would be very useful.

Are there any controllers doing that anymore?

I'd love to see a VST made that is essentially 3 synths in one: an Attack synth, a Sustain synth and a Release synth. Each programmed indepenently. Of course that could be done based on triggering from parts of an envelope...what VSTs can trigger from an envelope? It could certainly be done with just layering different synths, but I'd like to see this kind of thing built into one VST so you don't have to use multiple MIDI tracks or another program like Chainer.

Why do you think I put so much time into thinking beyond midi and about making improbable VST instruments?

Add any three things that exist right now, one from each category (plug-in instrument, midi hardware, and a program to deal with the midi) and there's gaping holes in making a real live-perfomance plug-in instrument.

Fretlessness is certainly the biggest thorn in my side. Why in hell can't there be a controller message (midi, osc, whatever) that gives one a defined amount of pitch slide? Continuum + Kyma does this but they cost more than my entire life is worth and Kyma ain't no plug-in.

And yet a plug-in, in a PC which can do whatever you tell it to, is the best place to make such things happen. Exquisite control... but then you run into the VST SDK standard which is co-dependant on midi's specifications. A vicious circle.

And by no means are we the first to run headlong into this problem. Like I keep saying, I'm sure the originators of all the great ideas that we are now bogged down in the details of their legacies were perfectly well aware of all this and sort of envisioned the next generation wising-up and leaping utterly beyond the very real hardware and processor limitations of their day.

Those limitations no longer apply but the paradigms are locked-in, and 99% of everyone who hears these conversations chimes in with "everything's a-ok!"

I would love to see a "latch" in the plug-ins that govern the entirety of the envelope, as defined by external control of some sort in addition to the internal envelopes. An override. I could go on and on but this isn't the place I guess.

I still want that force-feedback type of fiber-optic lit-up midi sitar rods thing we had posted a while before I started this thread.

[emdot_ambient]

...I would love to see a "latch" in the plug-ins that govern the entirety of the envelope, as defined by external control of some sort in addition to the internal envelopes. An override. I could go on and on but this isn't the place I guess...

I dunno, it's your thread, seems as good a place as any to go into it

Anyway, I need a better description of what you're talking about when you say a "latch" in the plug-ins, etc. I don't quite follow that.

[runagate]

...I would love to see a "latch" in the plug-ins that govern the entirety of the envelope, as defined by external control of some sort in addition to the internal envelopes. An override. I could go on and on but this isn't the place I guess...

I dunno, it's your thread, seems as good a place as any to go into it

Anyway, I need a better description of what you're talking about when you say a "latch" in the plug-ins, etc. I don't quite follow that.

Nothing in particular, just the abstract idea of a "latch" something that the data can latch onto, much as midi CCs or whatever do now.

What they notably do not do now is scale. Think of all the acoustic instruments you've ever played. There's attack techniques that each instrument has. Being a sax player I think of stacattos, any kind of slow quiet-to-loud dynamic you'd please, slurs or tongued note changes.

Tuba blats, bass slaps, the difference between a low trumpet note and a high-pressure high overtone note.

Another thing envelopes basically never do is have expression control release. I know that's supposedly what CC#10 does (hope I got that right off the top of my head) but since between the mdi standard and the VST standard there's no good, uniform way of dealing with this most developers don't. And no one will until there's some likely benefit to the end user, really.

But all "instruments" have these features, which is what makes intruments a part of the tone palatte of arranging songs. And I am in no way refering to trying to emulate specific instruments via synthesis. In a way that's easier, as you've got a definite end-product you're desiging the sound of. (I mean in terms of generic controller expression, not getting the actual synthesized sounds). For instance, Miles'Tone gets at the fundamental expressions needed for trumpet through "hard-wired" midi CC assignments in the plug. There's that "adaptive performance" violin VSTi that you have to delay by a bar or somesuch but it interprets how to sound based on the playing technique of the notes you play and how that'd sound on a real violin.

What I'm talking about it making distinctive sound design expressivity performance options. .. .

ok I'm hitting "submit" as caucasian females are piling on me irl. hard to type

to be continued

[justin3am]

Those krazy caucasian phemales, talk of conceptual controllers just doesn't get them as excited as it does us gnerds.

[Liquidclear]

Those krazy caucasian phemales, talk of conceptual controllers just doesn't get them as excited as it does us gnerds.

Maybe a Phallic MIDI force-feedback controller, no?

[justin3am]

My wife used to work at a store that sold a vibrating device that connected to a USB port and could be controlled remotely via interweb enabled software. I always speculated that the software could be made to interface with a midi device. I figured that it would garner more excitement than it did.

[emdot_ambient]

Those krazy caucasian phemales, talk of conceptual controllers just doesn't get them as excited as it does us gnerds.

Maybe a Phallic MIDI force-feedback controller, no?

Yet another reason to see your doctor about Viagra!

Actually, maybe that's the answer. We need something to get the money and creative brains of Big Pharm involved in musical interface design!

[runagate]

Ok, to continue parts of my previous rant, and Shiva knows I shouldn't be trying this off the top of my head, It'd be awfully easy to have velocity-scaled envelopes in addition to release-sensing. It's almost inconsequential in terms of data organization, though from the point of view of sound design it'd be a little time consuming.

Which brings to mind modularity of such things. There's no reason there can't be embedded in the data control flow templates for such things as envelopes and the like that are reusable. Envelopes can also be looked at from the point of view of time-absolute or, in the realm of DAWs we're generally mucking about in, subjective time based on tempo, bars&beats and the like. Scalable. And once scalable modularity is added to velocity sensitivity and on-the-fly envelope switching as a separate performance parameter (think something like the modwheel) you've got the velocity-based expression control added to performance control (put knob in position x for stacatto, y for rubatto, or whatever you'd like) just in that one realm of synthesis you've suddenly made instruments, and the design of instruments more precise, easy, expressive and exciting. Think of all the modulation weirdness we try in sound design just to get some variety into our synths. Being that I makes notes of all this crap all of the time I shouldn't be making off-the-cuff comments. I should spend the time to make it lucid.

[Shane Sanders]

Imagine an instrument that is designed somewhat like a stringed instrument:

Eight thin glass rods for 'strings' (each about the size of the A-string on a bass guitar). In reality, they'd be semi-circular because we'd want a flat surface on the side that mounts to the 'fretboard' (more on that in a sec).

Inside the rods it would have heat sensors per fret, so that if your finger lingers on a fret, it would do something (some assignment). It would, perhaps, make the joystick on the instrument shift to a subtle vibrato mode, then return to a larger intervallic relationship when your finger isn't heating up a fret.

The rod would be continuous because the fret demarcations are being determined by your finger reflecting some light back into the projector underneath. So it would know where you are on the rod in a very fluid way. Perhaps we'd need little reflective dots on the pads of our fingers to achieve a consistent tracking reference...yadda yadda yadaa

Oh I can dream can't I?

[runagate]

Imagine an instrument that is designed somewhat like a stringed instrument:

Eight thin glass rods for 'strings' (each about the size of the A-string on a bass guitar). In reality, they'd be semi-circular because we'd want a flat surface on the side that mounts to the 'fretboard' (more on that in a sec).

Inside the rods it would have heat sensors per fret, so that if your finger lingers on a fret, it would do something (some assignment). It would, perhaps, make the joystick on the instrument shift to a subtle vibrato mode, then return to a larger intervallic relationship when your finger isn't heating up a fret.

The rod would be continuous because the fret demarcations are being determined by your finger reflecting some light back into the projector underneath. So it would know where you are on the rod in a very fluid way. Perhaps we'd need little reflective dots on the pads of our fingers to achieve a consistent tracking reference...yadda yadda yadaa

Oh I can dream can't I?

I've given a lot of thought to something very similar (including the type of note-on interface for a midi string-like instrument that would be inspired by strums, slaps, attack feel based on nearness to bridge, etc) but at this moment a plug-in wouldn't have a useful way to interface with all that beauteous control expression.

I love your ideas, Shane

[runagate]

Let me ask a question and see if anyone knows:

If there were a data protocol being sent from a hardware instrument controller that was based on advancing the cause of sound design what form would be best for that data to take?

The 16-channel midi, with it's " continuous controllers and the other messages being sent with a resolution of 0 to 127" standard is what we have now. Obviously with USB 2.0 being the standard by which to transmit that data those restrictions are ridiculously easy to overcome.

If I had millions of dollars to make dream instrumental controllers, but there was nothing yet designed to receive those messages like I'm imagining, what would be the best format for that data to take on the assumption that I would want plug-ins that actually understood these messages to take? There's no reason such a thing couldn't send midi and some new protocol as the situation warrants it.

I have no ideas off the top of my head, so being that I don't have millions of dollars I may as well ask here.

[justin3am]

Thats a really tough question! When you think about it, great care was taken in the development of the Midi protocol. Some of the greatest minds in electronic intruments had their hands in that cookie jar. Back then you had to balance the amount of data with the amount of expressiveness... that isn't as much a concern today. I think the main considerations would be the ability to adapt to changing needs and the two way interaction with the interface and the sound source. I do agree that there needs to be a more modular approach to the messages being sent but I think that the interpretation of those messages should remain on the side of the sound source rather than the controller simply because we do not know what we could want to do in 10 years.

I think that if I were to develop a new data transfer protcol for controllers I would primarily be concerned with taking advanage of increased bandwith and local memory as well as once again attempting to future proof the new technology.

[runagate]

I do agree that there needs to be a more modular approach to the messages being sent but I think that the interpretation of those messages should remain on the side of the sound source

Hmm. That's not what I mean, and I don't have a vocabulary to explain it.

......

......

Ok, how about this. I'm thinking of the controller data being a protocol NOT of either the receiving plug-in nor the hardware.

Sort of "messages with wiggle room"

I'm thinking of adding more responsibility outside the "sound source"

But in a way that ...

You see, I should not be "shooting my mouth off" ex tempore.

Ok, let's take the "envelope" as an example.

The protocol would contain a message "this type of envelope, this kind of time domain information"

Either end could select the way velocity layers for the envelope could be deployed, or even from something filtering in-between. It shouldn't matter; it should be allowable at an arbitrary point, and notify all parties involved of that choice. We're in the era of 2-way feedback, we should be taking advantage of it.

Thus, the synthesis would have to be developed in such a way that these options are meaningful in some way. This happens now, it's just that the old, old protocols demand adherence to a different standard that's no longer necessary. You can see developers struggling with this all the time, and the genius workaround they've invented take up a lot of their time when there could be something, which is what standards are all about, which enables a vastly greater degree of possibilities and potential but it has to be very well thought-out, open-ended, and agreed upon. I understand that, certainly. It doesn't mean that we should stop thinking about it; right now there's laregly a gaping silence on the issue.

I promise I will make this make sense at some point.

But as I've only a hazy idea of what "packets" of midi data are sending (from the point of view of the electronics, not how I as a user are to interpret them) I wouldn't know where to beging to find out how the 1s and 0s are being re-assembled into "midi language" by the hardware and software.

[emdot_ambient]

I'm sure I'm totally missing your point but it kind of sounds like an object oriented system.

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. It is based on several techniques, including inheritance, modularity, polymorphism, and encapsulation.

Object-oriented programming roots reach all the way back to the 1960s, when the nascent field of software engineering had begun to discuss the idea of a software crisis. As hardware and software became increasingly complex, researchers studied how software quality could be maintained. Object-oriented programming was deployed to address this problem by strongly emphasizing modularity (discrete units of programming logic) and reusability in software.

[Shane Sanders]

The thing nobody has done so far in a comprehensive manner, not even Synth Axe or Starr Labs, is really target performance controller gizmos as contextual devices.

I think one of the big things missing from controllers in general are easy to use three-way toggles that shift an aspect of a controller knob (or whatever) into either a different mode of the same task, such as moving a pitch-bend joystick into a narrower range of possible values for a moment (for vibrato) yet allowing it to still do half-step or larger intervals if the performer does something that can communicate his desire for that to happen. It could also, if the performer squeezes the tip of a joystick beyond a threshold, become a vibrato expression that also introduces a high-end rolloff of some sort. Really subtle stuff that you'd be thinking about as you made a powerful patch, this is what I have in mind.

It all boils down to providing the performer with an ALT key for changing the function of a thing on the fly, but doing it in such a way that it's fluid and works with the action of being a performer instead of these silly controllers that have 30 knobs that are all the same color in an array so tight you can barely fit your fingers on them without touching other knobs.

I actually have a tactile controller mechanism drawn up (in 3D) that has not been done yet on any device I've seen so far (in the manner that I'm thinking). I'd share but I want to patent it first. It's so obvious that I can't believe that someone hasn't done it yet.