VST tone portamento and other effects

[nobuyuki]

Several effects don't seem to work yet or aren't implemented for VST's, and the adoption of VST's for standard tracking style might be increased if effects can be accessed in a more straightforward way than the current MIDI macros.  Specifically, I was hoping that Gxx (tone portamento) would be implemented.  Furthermore, I'm not sure this applies to all VST's, but note slide data doesn't seem to reset on a new note action, which messes up many leads if they're changed from samples to VST unless the appropriate "opposite" portamento is added to the channel when a note isn't playing  :shock:


I'd also request that Mxx (channel volume set) and Dxx (volume slide) be implemented in the chain between the VST output and output to the speakers, so that finer control beyond simple velocity can be implemented and all VST's can be treated more similarly to samples (for example, "string poppers" are next to impossible using VSTs)

[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.

[Saga Musix]

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.

Wrong, if that was the case, what would MIDI CCs be for? A great number of MIDI CCs is standardized, including those for tone portamento, which is why f.e. Exx and Fxx work with all plugins that support pitchbend.

[psishock]

good luck betting your luck, that your VST(i) of choice will use standardized MIDIcc. And what about the hundreds of different cc-s, that arent (effectively cannot be) included in standards? Thats why i've said his better off, by transporting his habits to midi automation, rather than hoping, maybe it will support his favored set of cc, and maybe it will work as wanted.

[Saga Musix]

The number of VSTis using a wrong MIDI CC can be neglected. And whoever doesn't comply to those standards is just dumb and should not write VST plugins in the first place. All plugins I somehow wanted to pitchbend worked properly.

[nobuyuki]

The number of VSTis using a wrong MIDI CC can be neglected. And whoever doesn't comply to those standards is just dumb and should not write VST plugins in the first place. All plugins I somehow wanted to pitchbend worked properly.

Thanks for that.  Nothing in my mind would've said that this is technologically unfeasible, either.  Though, I can see how it would be tough to implement something like Tone Portamento since the replayer would probably have to keep something like a "running tally" of the amount of pitch bend it needs to send the VST.  For convinience and for the sake of control in the tracker tradition I think it's still important we don't abandon the relatively simple and useful tracker effects with our VST's.  

I fundamentally disagree with psishock's argument -- if I wanted to work with a more traditional studio setup, I would simply use FL, LMMS, or something similar.  My primary interest is in seeing the experience of Modplug Tracker extended to the modern era without inconsistencies and anachronisms.  That was of course the primary motivation behind starting this thread.  There are much better programs to leverage automation and MIDI controllers with than MPT.  MPT should be for tracking, first and foremost.

Edit:  And that's not to say I'm not for controlling every value directly from the tracker, just that its implementation should be fairly straightforward and fit within the paradigm the program already presents to the user without introducing new, inconsistent paradigms.  "Program Control" columns look somewhat promising in this regard, but I'd still like to see all the standard effects implemented via commands where possible, and the option to "override" the output of the VST and directly manipulating the stream as it would a sample when not.  A long pipe dream, for sure, since there is a relatively easy workaround by "baking" a VST into a sample, but nonetheless there are some effects that are still better/faster generated without having to go into multisamples....

[psishock]

that's why i've asked, are you trying to do heavy VST work, or just basics. The tracker fx are laughably incompetent for more interesting purposes, and you will end up using automation. So why messing with multiple control system, when you can master 1 perfect (dont hafta learn any fx hex code, just click on the desired control and automate it), then use it for anything you want, on the fly.

My primary interest is in seeing the experience of Modplug Tracker extended to the modern era without inconsistencies and anachronisms

i know what you're thinking and feeling, but the VSTi era is the modern, and the tracker based are the old, fading ones. They are limited from many sides by design. Trust me on this, or look at the world. You will eventually move away from it, or stay limited. My prediction, that it will shrink to very small subculture, like C64 programing and music (almost like dying). But of course, there will always be people who will see at it, as an interesting toy to play with, so it will stay with us, wont disappear totally.

[Saga Musix]

that's why i've asked, are you trying to do heavy VST work, or just basics. The tracker fx are laughably incompetent for more interesting purposes

You can say the same about automation/MIDI/VST. Just think about how you woud "emulate" effects like Ixx, Jxx, Mxx (esp. with several channels of the same instrument having different channel volume), Yxx, ... Yes, there are workarounds to make it work, but that's not the point. So I could just say "MIDI is laughably incompetent for more interesting purposes".

[psishock]

Jxy = arpeggio, VSTis have a lot more sophisticated and advanced arp systems, that you can setup and control in detail. Tracker version is primitive yes.

Mxy = every channel has a master volume that can be automated with a click, and the master output has a master volume bar too. No problem here on either side.

Ixx = Its the tremor. Well here comes the concept of the LFO. The LFO is a huge tool, gives every kind of custom or standard wave like repetitions. And can be setup totally easy. One of the effects of it, routed to volume, with a square wave can be the tremor. But the custom possibilities are so great here, i safely can say, that the tracker fx "implementation" of it is very primitive.

Yxx = Panbrello. Open a LFO, routed to any channel's pan. Dont get my started how complex are the possibilities again with all the waveforms. The tracker implementation is again primitive and limited.

and these stuff are now "workarounds" but a very simple ways to archive the wanted effects. MIDI/VST is a very powerful technology, hafta learn the possibilities, and see how easy can you control very wide range of stuffs, that were impossible with tracker fx, because of their limitation and system.

Its way different logic, you arent forced anymore to use pre-implemented effects, feel handicapped by their maximum ranges, limitations. You are free to build anything you can imagine, and even chain them, because you know how they work, and how to do so.

[Saga Musix]

Jxy = arpeggio, VSTis have a lot more sophisticated and advanced arp systems, that you can setup and control in detail. Tracker version is primitive yes.

Someone who's for example making a modern remake of a chiptune might not want to configure the arpeggiator of his synths for 5 minutes until he can make a simpe chiptune-alike arpeggio but rather write a sequence of J37 effects right away. Most arpeggiators that you find in synths are more like a retrigger than an arpeggiator in the MOD sense, meaning that they just define at what interval the sound of the synth is retriggered - MOD arpeggio never intended to be such a trigger effect, but more like a quick cycling through different notes - that's something completey different which you cannot compare to MOD arpeggio.
Also, you cannot simply turn off a synth's arpeggio as you can with Jxx (where you just don't write out the effect anymore) - ooooooooh right, you can automate it, but that's just a crappy workaround.

Mxy = every channel has a master volume that can be automated with a click, and the master output has a master volume bar too. No problem here on either side.

No, not it we're talking about channel volume here. If Mxx would just mean that all note volumes are multiplied by a factor, then it could be done in the same way with a vst. But if you assign several volume-controlled channels to the same vst, this is not possible, because a vst just has one master volume, whereas a sample has as many master volumes as there are channels.

If you count LFOs as VSTs, well, ok, but using an LFO to control a VST parameter is not possible in OpenMPT.

[psishock]

arps. Well as easily you set up J37, a person who is experienced with his synth and arps will set it up, as fast too, in this simple form. The normal aprs arent retriggering the sound but are just gliding through different notes, also you can chose the length of the steps, which step to do particular stuff (glide to another note, or retrigger it), or randomize it (or the imput note order). Or you can chose the speed, arpeggio modes, bpm sync the speed or make it tempo based, control the shuffle, and many more misc stuff. Trust me, a simple arp command with total control of 2 is reeeealy primitive, there are so much more possibility.

And you can start saying: well sure, but i dont need anything more than those 2. I say, you shouldn't base other peoples needs and expectations  on yours. We didnt started this night chat with personal demands, but with facts, about limited and primitive systems.

No, not it we're talking about channel volume here. If Mxx would just mean that all note volumes are multiplied by a factor, then it could be done in the same way with a vst. But if you assign several volume-controlled channels to the same vst, this is not possible, because a vst just has one master volume, whereas a sample has as many master volumes as there are channels.

We're talkin about the same stuff i think. We have routing possibilities here, so you can route 1 VSTi to many channels ("splitting" the sound if you like), much the same effect, as you would experience with the samples. And every channel has its own local volume mixer, so 1 played VSTi, routed to different volume based channels will sounds as loud or calm, as the routed channel are preset. I hope it's more clearer now, i have troubles sometimes, with explaining stuffs .

Also, you cannot simply turn off a synth's arpeggio as you can with Jxx (where you just don't write out the effect anymore) - ooooooooh right, you can automate it, but that's just a crappy workaround.

If you count LFOs as VSTs, well, ok, but using an LFO to control a VST parameter is not possible in OpenMPT.

Well good arguing point . I think too, that you shouldnt blame the incompetence of OMPT, against the standardized MIDI/VST system.

LFOs are quite basic input forms on most vst hosts. Also turning on/off any VST fully, or internal controls (like arps) are archived with one simple x001 or x000 command (can be triggered from the pattern effect row too, dont even need to be automated). I really wouldnt call this "crappy workaround" neither, but a most natural thing to do. Dont need it anymore, bing, turn it off with an off command.

[Saga Musix]

a person who is experienced with his synth and arps will set it up, as fast too, in this simple form.

there is nothing faster than typing "J37".

Trust me, a simple arp command with total control of 2 is reeeealy primitive, there are so much more possibility.

Maybe I sometimes want a simple, "primitive" command instead of 1000 features? Every thought of that? This command is perfect for that. For everything else (like an arpeggiated bassine) I can still use direct notes or a synth's arpeggio.

Well good arguing point . I think too, that you shouldnt blame the incompetence of OMPT, against the standardized MIDI/VST system.

Well, sir, we're talking about whether OpenMPT should support the commands that you call "primitive" with VSTs as well or not. I don't care if you have LFOs and stuff in buzz, renoise or somewhere else, that is besides the point.

[psishock]

there is nothing faster than typing "J37".

Maybe I sometimes want a simple, "primitive" command instead of 1000 features? Every thought of that? This command is perfect for that. For everything else (like an arpeggiated bassine) I can still use direct notes or a synth's arpeggio.

well yep, nothing beats J37 in speed, but i can assure you, setting up 2 transpose points on synt arps would not take much more time too. My basic idea was to use one system for every command, and avoid having some "quick" ones, then if we need more advanced stuff, dig onto automation. The composing imho is much more organized with less scattering and distractions, and if we're talking about serious composing, we surely will dive ourselves to detailed controls anyway.

Well, sir, we're talking about whether OpenMPT should support the commands that you call "primitive" with VSTs as well or not. I don't care if you have LFOs and stuff in buzz, renoise or somewhere else, that is besides the point.

hmm hmm, fair enough indeed. ^_^

[Harbinger]

Doesn't matter how fast you can type J37 -- if you never use it, it's worthless.

While on the one hand i had never expected tracking software to emulate an LFO (which makes Jxy a feature), the emulation of many different types of synth techniques is, yes, very primitive in tracking software. I cut my teeth on synthesizers, so i have to side with psishock on his assessment of MPT or basically any tracker when it comes to sound creation. Trackers are sound movers FIRST, sound creators second. MPT has never claimed to synthesize sound, but it does claim to "assemble" it, and for a free piece of software, i happen to think it does it well. All of the synth-emulation commands only add a little to its capabilities.

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. When you work with MIDI you're stuck with the samples it's given. Fortunately we live in a time when trackers have some MIDI capabilities (which means, for example you can manipulate your custom LFO), AND some sequencing software has tracking capabilitied. Plus there are synth modules in the form of software, which many trackers can access (if they can host VSTs) -- ours included. So with MPT, yes i may be using "primitive" techniques, but since rewbs added VST capabilities to MPT, we're at least not limited to only sample manipulation. And if i really want to go full-board into synthesizer manipulation, i can use Renoise -- but the cost for that is a LOT of time devoted to tweaking (or at least learning how to tweak)! :wink:

[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....