Started by nobuyuki, April 24, 2010, 16:06:02
QuoteDoes 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
Quote from: "nobuyuki"More importantly, I feel that it is an argument I feel is off-topic to the scope of this thread.
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.
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.
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....