VST tone portamento and other effects

Started by nobuyuki, April 24, 2010, 16:06:02

Previous topic - Next topic

Saga Musix

I have never looked into the Fxx/Exx code, so I cannot tell. I think the main problem is the pitchbend range, which is +12 maximum for many VSTis. And after one portamento finished, you re still having the old note as a base note, so you cannot simply continue sliding to other notes.

Does MPT attempt to send any controller messages to VSTs when initializing them?

QuoteSpecifying pitchbend sensitivity in a controller message could pretty much rule out most VST's from misbehaving in this fashion
I don't think that this is a good idea. Many synth1 patches i use actually have different pitchbend range values on purpose.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.


Quote from: "nobuyuki"More importantly, I feel that it is an argument I feel is off-topic to the scope of this thread.
Not entirely. When you've started to use the word "VST" you've leaved all what are trackers essentially about (sample manipulating) and started to speak about sequencer functionality. I will quote Harbinger too:
Quote from: "Harbinger"Personally i'd rather be sequencing, but one thing i will never be able to do with a sequencer is cut, slice, loop, pitch-bend, and otherwise grope any sample on-the-fly i want into a song. Trackers can do this.
What we're forgetting that these tracker features are basically a hard coded automation hex codes, for the tracker's internal sampler control. If you're getting a decent sampler VST, you will be able to do these as well in any sequencer, even a lot more with more professional products, and i've seen really cool ones where trackers cant get near of, even with their strong point, sampler functionality.

You have maybe learned all the hex codes for the sampler manipulation, but basically what you really need is a redesigned automation system, that makes the whole sound manipulation even easier and faster than learning and controlling merely the tracker sampler with internal fixed hex automation codes. Think about it, how many parts of the sounds can you control in a channel at a time? Struggling with 1 (or two if we include the volume bar as a workaround, or some mixed tracker fx)? Surely that is nowhere even close enough. If every single (sampler, VSTi, vst) control has it's own unique "bar" on demand, and that automation can be setup, accessed and manipulated with a single left or right click to the chosen control (as we have on advanced trackers and sequencers), it would be a much more sophisticated and easier way to manipulate any given aspect of the sound of effect. It will able you to overview every control's value easily also, you wouldn't think anymore about Fxx/Exx or any codes (and their limitations) anymore, but control every single state of any given midicc at your will.

I'm trying to say that these old hex effects are really holding the trackers back and while you think it will make it fast to work, they are limiting you to a certain closed system, and to use them only, while throwing every other controls away. With redesigned, proper automation system you would not only work faster, but you can forget all the limitations that the old controls and channel fx gave you. The "closed" hard fixed fx codes are essentially wrong approach, each of those tracker sampler commands should be controlled separately with midi automation too, like the rest.
I'm as calm as a synth without a player.  (Sam_Zen)


if you don't think you're going way off-topic regarding the scope of this request, then I think you must be very narrow-minded.  I don't think this is the right place for your pontificating on what sort of program MPT should be in the general scope.  Why don't you make your own thread which covers that, instead of trying to force your ideas into this one?  

It's not like I necessarily disagree with better parameter control, just that the ones I mentioned in the original post should be internally consistent with the existing paradigm. New paradigms are the topic of another thread yet to be discussed.  Please don't hijack my thread any more.


roger sir, i will not hurt your precious topic anymore with filthy, very narrow minded posts, relax your body. :luvvv:
I'm as calm as a synth without a player.  (Sam_Zen)


Quote from: "psishock"VSTs.... well for starters you cannot use standardized tracker effects for them, every synth ha its own set of controls for midicc, no way we can "assume" how did the developer built his own VST. And to be honest, you can archive much much greater control and freedom with setting/automating midicc-s, and chaining VSTs to one on another, routing the sound signals. Its a much more complete way, than relying only to tracker effects.

If you truly want to work, heavily with VSTs, you have to let the sample based, tracker effect system totally go. Its not designed for VSTs, and the old habits will only drag you down and make your life harder, with the new technology. Learn controlling your composing process with midicc-s, the tracker effects are (arguably) heavily limited in many ways.

The pitch shift control on most MIDI controllers works with just about everything. If you can just make it so tracker effects are interpreted as pitch information, there shouldn't be a problem.

I really want a soundfont player that supports pitch bend...

Basically I want to jazz up some of my old stuff. SF2 support is shit, so I have to use a VST soundfont player. And I can't do pitch shift and vibrato with that.


Quote from: "nobuyuki"sheesh, it's almost as if trackers weren't made for sequencer/synth people, but for tracker people.  Remember what the paradigm is here.  I don't think the developers are trying to turn a fork into a hammer here;  I just think that the tracker paradigm is still adopted for a good reason, and that the built in effects are exactly what some people want for their sound.  Recreating them in automation is a pain in the ass when it shouldn't be, and exposing the functions without actually the functionality is just plain bad interface design to boot.  

More importantly, I feel that it is an argument I feel is off-topic to the scope of this thread, which was to request expanding the feature functionality from the built-in tracker functions to more fully (and consistently) cover VST's;  a request I do not find unreasonable in principle, even if it will require some effort in execution.

Now, getting back on topic... Jojo, do you think that having a lookup table for note-to-note slide transitions in pitchbend controller messages would make Gxx easier to implement?  I am assuming that Exx and Fxx's implementation presumed that there was some sort of default for the number of semitones the bend value represented that would remain mostly static between VST's.  However many VST's are initialized to a different sensitivity value from the default ones the pitchbend controller messages are effected by would determine how reliable Tone Portamento would be.  But, whereas Exx and Fxx can be worked around without needing to send the pitchbend sensitivity RPN manually (through some sort of macro or automation event by changing the values), Tone Portamento would break completely if the default semitone range was off the default.

Does MPT attempt to send any controller messages to VSTs when initializing them?  Specifying pitchbend sensitivity in a controller message could pretty much rule out most VST's from misbehaving in this fashion, since the replayer could then reasonably expect a consistent linear value mapping effects values to controller messages.  A static table of note-to-note slide values could then be constructed based on the default (and maybe later, the current) RPN sensitivity value, and Gxx would simply determine a ratio of how the looked-up value is applied per tick, stopping the application of controller messages when it reaches 1:1 with the looked-up value (ie:  the full value needed, in pitchbend controller messages, for note A to play at note B's pitch).

The channel volume stuff is another matter entirely....

Personally I use trackers for the layout, not because I like being limited to samples.


I'm bumping this because I think it's important.

At the end of the day I have tracks composed in openmpt making extensive use of tracker effects and I want to be able use proper layered soundfonts and VSTs with them so they don't sound like Amiga music. I like the interface of Trackers more than the history.


I was thinking this could be implemented by giving us the option to assign unused effects to vst/vsti buttons/knobs/etc manually so that would bypass you guys having to find standards for all vsts. For example Jxx to plugin param 0 when it is applied to that vst, it means more work for the composer, but also means more flexability
No longer helping. Do not expect replies.

Saga Musix

Since VST "Buttons/Knobs" are either representations of MIDI CCs or VST Parameters, there are already ways to control them (Zxx/PC Notes). I have a half-working Jxx implementation for VSTi, and all other volume effects should also work "out of the box" with my new macro system. It just needs some more time to develop. Binding Jxx to a plugin parameter will most likely not do anything reasonable because no plugin will probably use a similar mechanism as trackers do.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.