From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
VST3.1 comes with two convenient "wrapping" tools, enabling VST3.1 plug-ins to be transformed ...– for older DAWs – into the VST2.4 standard.... Further features are the support of MIDI poly pressure, ... time accurate parameter group editing, delayed opening of the plug-in editor while loading a project/preset, "dirty status" allowing the plug-in to communicate generic changes to the host...
http://www.kvraudio.com/news.php?id=14727 http://www.steinberg.net/en/company/developer.html
trogluddite ·
So we can wrap 3.1 plugins for old hosts - but not old plugins for 3.1 hosts. I smell compatability problems brewing... and SM lags behind the standard yet further... 🙁
rl ·
I have the feeling VST 3.x will have a hard time before beeing accepted. How many hosts are out there with VST 3 support?
infuzion ·
rl wrote: I have the feeling VST 3.x will have a hard time before beeing accepted. How many hosts are out there with VST 3 support?
A few, but I don't think of a majority. The point of VST3.1 SDK is that using a single SDK one can export to both 3.1 & 2.4, which SM is also missing.
IMHO, I think the VST standard is more problems than it is worth. I think if a 2-way + multi-slave rewire was made, then the standard can go to all standalone EXEs.
infuzion ·
Steinberg is now up to VST3.5: One of its highlights is Note Expression which relies thoroughly on VST 3.5. Note Expression enables individual notes in a polyphonic arrangement to include multiple controller information, providing the ultimate flexibility for note articulation. ...“With Note Expression we break through the limitations of MIDI. Articulation messages are no longer bound only to channels, but can now be used for every single event,” remarks Yvan Grabit, technical lead at Steinberg. VST 3.5 also provides a new, XML-based controller interface for exporting and grouping plug-in parameters, while allowing VST modules to add individual context menu entries for customized configuration.
http://www.steinberg.net/en/company/pre ... st_35.html
rl ·
(running the risk this thread turns out to be a private conversation between infuzion, trogluddite and me)...
I once posted a question on the steinberg dev mailing list, which hosts/plugins will support those new uber-features like note expression controllers in the future. I got no answer, instead a flamewar was started about the point of this feature.
But I agree wholeheartely! SM is a bit behind on the VST standard. Much worse since VST export is the killer feature of SM.
trogluddite ·
It does seem to me that, while keeping VST as a nominally open specification, Steinberg have been adding features to it with the sole aim of being the only developer with products that actually support those features - rather than because there is any significant demand from developers or end-users. Of, course, they are commercial company looking to protect their market share - with stiff competition from well specified and much cheaper alternatives (e.g. Reaper) - so it is to be expected that they wouldn't make life too easy for other developers. However I do think that they are shooting themselves in the foot when they decide to lose back-compatibility of older VST spec's - it's one more temptation for users with a folder full of favourite 'go-to' VSTs to migrate to other platforms.
The note specific articulations do look like a powerful and innovative feature - especially if you are the kind of musician who likes to tweak tunes to perfection in your sequencer, or use score notation (e.g. users of large orchestral sound libraries) - but for my money it is seriously hampered by the lack of an input device capable of playing the articulations intuitively in real time. After all, how many controllers even support poly AT?
I think that what is crucial for SM is to support the VST standards to a degree that at least allows the features that we already have to be supported by the widest possible range of hosts - and that may well imply that OutSim will have to submit to Steinberg's 'bullying' to some degree (not to mention addressing many of the other issues that hamper SM's suitability for commercial development.) - otherwise SM becomes no more than a 'DSP novelty toy', even for hobbyists like myself.
infuzion ·
trogluddite wrote: However I do think that they are shooting themselves in the foot when they decide to lose back-compatibility of older VST spec's - it's one more temptation for users with a folder full of favourite 'go-to' VSTs to migrate to other platforms.
The VST 3.x SDKs have built-in support for VST2.4 also, not sure if it will be a 2nd export, or the same VST will have a dual-identity in one DLL...
rl: you are such a troublemaker! Note expression is useful for guitar controllers I guess, where you would pull one note but others are still sustaining normally.
DigitalWhiteByte ·
trogluddite wrote: I think that what is crucial for SM is to support the VST standards to a degree that at least allows the features that we already have to be supported by the widest possible range of hosts - and that may well imply that OutSim will have to submit to Steinberg's 'bullying' to some degree (not to mention addressing many of the other issues that hamper SM's suitability for commercial development.) - otherwise SM becomes no more than a 'DSP novelty toy', even for hobbyists like myself.
My vision is that Outsim, chose to create a product that fails to achieve professional plugin deliberately (or under consideration by someone?) and is more oriented to use for teaching ... you imagine how VST devalue the market, if every one could create his professional VST sibling or so, compared to those developed at low level? A complete disaster VST market. Then I remember is my vision, because I do not think developers outsim have difficulty in implementing an improved system for timing and the new vst specific, I think it's just a matter of monetary agreements between the parties, also because the Its only direct competitor is synthedit. I hope it remains a vision and not a mere reality.
TomC ·
DigitalWhiteByte wrote: I do not think developers outsim have difficulty in implementing an improved system for timing and the new vst specific
Let me slightly disagree with you. From what I've seen over the years (one bug gets fixed here, resulting in a bug there) SynthMaker has some inherent design flaws and needs a complete re-design, especially the core elements. And that's a lot of inconvenient work. As good as the guys surely are at coding, software design is (or was, back when they started SynthMaker) not one of their strengths.
I would be surprised if anyone would intentionally NOT wants his software to be THE development tool.
Tom
trogluddite ·
I agree, it seems that decisions made early on in the design of SM have placed OutSim in a trap with regard to making certain improvements - for example, a major rewrite of the trigger system for better timing would almost inevitably lead to huge problems with back-compatibility of existing projects. The release of FlowStone, using the same framework as SM, would also seem to indicate that such big changes to the underlying architecture are very unlikely - they have obviously made the commercial decision that it is more cost effective to push the current technology into new markets, which is understandable given the limited resources of such a small company. What is most frustrating is that there are some apparently less profound changes that could at least alleviate some of the most often encountered shortcomings - for example; a stream method of generating MIDI events or triggers, or access to mem buffers from the code/assembly blocks.
CoreStyler ·
trogluddite wrote: I agree, it seems that decisions made early on in the design of SM have placed OutSim in a trap with regard to making certain improvements - for example, a major rewrite of the trigger system for better timing would almost inevitably lead to huge problems with back-compatibility of existing projects. The release of FlowStone, using the same framework as SM, would also seem to indicate that such big changes to the underlying architecture are very unlikely - they have obviously made the commercial decision that it is more cost effective to push the current technology into new markets, which is understandable given the limited resources of such a small company. What is most frustrating is that there are some apparently less profound changes that could at least alleviate some of the most often encountered shortcomings - for example; a stream method of generating MIDI events or triggers, or access to mem buffers from the code/assembly blocks.
Maybe they need to stop to <---> connect SM to Flowstone. Then continue separated programming.
VST 2.4 would be perfect at that time. Many (all i think) host fit this SDK so is not necessary to port 3.x Host with 3.x support are really less compared to 2.4
infuzion ·
CoreStyler wrote: VST 2.4 would be perfect at that time. Many (all i think) host fit this SDK so is not necessary to port 3.x Host with 3.x support are really less compared to 2.4
I think you missed the point that the SDK allows both 3.5.x & 2.4 export in the same SDK?
Strange, only a 0.0.1 release in 1.6 years.
Moot point anyhow; how many 3.5 VST hosts out there? How many mandate 3.x & will not load 2.4? 2.3 is getting sketchy though...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker