The state of synth development (why no 64-bit/Mac/etc.)

[chk071]

Sooner or later devs won't sell a single copy anymore if they don't release a 64-bit version of their plugin.

I have to take issue with that. I've decided to stay with 32-bit software for all audio, and I know a considerable number of others who have done the same. I/we? have no intention of switching to 64-bit ever. Considering the lack of significant benefits, why should we? I don't need the extra memory and don't feel the sound quality is any better.

This 64-bit whining was old 6 months after it first started. Let it go. Take a deep breath ... and get on with a life. Some of us are thoroughly sick of hearing about it.

I don't see anyone who is whining here. Just some people who are wondering why in 2015 Synthedit doesn't export 64-bit VST's. Besides, i can tell you that you WON'T stick forever with 32-bit stuff, because it will cease to exist one day. Since Windows Vista you can't install 16-bit installers anymore, and the same will happen with 32-bit one day. That day may be far in the future, but don't "whine" when it happens one day.

[glokraw]

32bit Reaper and linux wineasio aren't going anywhere, and synthedit plugins
will work fine in reaper forever, for anyone who wants to use them.

If at some point motherboard manufacturers block 32 bit setups,
people will just get some backups from the Goodwill, and recyclers.
If someone happily uses a pci soundcard, it's probably a good idea
to buy a few mobos with real pci, put 'em in a faraday cage with
a supply of peripherals, and playback devices.

[chk071]

The question is how long it makes sense to keep on using 32-bit. Are there even non-64-bit CPU's being manufactured still? Don't get me wrong, i don't see 32-bit dying for the next 10-15 years, but it WILL cease one day.

[ccDuckett]

One thing that I think will be sadly dwindling is the number of small developers who release synths or FX that are off the beaten path. Why? A lack of "Beginner/Intermediate" programs like SE or SM/FS that can export in 64-bit (I'm not sure what's going on in Macland because I don't own one). Sure, anyone can see that during the peak years for SE/SM, there were a ton of crappy synths and FX being released all the time- but there was also some very unique gems that didn't work or sound like everything else.

How many of these resulted from people who had interesting ideas for instruments or FX, but didn't "know how to code"? Many people who "know how to code" often are in a position of "My skills don't come cheap, and certainly not for free", and there's nothing wrong with that. Very talented people in any field deserve to get paid for what they do, if the market supports it.

However, the number of people who are:

-good coders
-have an interest in plugins
-have a healthy creative streak
-are willing to devote the time and energy it takes to not only develop the plugin, but deal with the potential flood of user feedback/support/FR etc.

are few and far between.

At least with programs like SE, there's a gateway for those who are interested in developing their own ideas, but who are intimidated by the prospect of learning C++ etc. Those that truly suck at it will soon cease their efforts in any case, while those who show a certain proficiency will either improve with time, or attract the attention of those more skilled who are willing to help.

The problem with something like Reaktor is that it's a proprietary format; only those who've shelled out the $$ for it can both create, and enjoy the best of what's on offer. There's plenty of great ensembles, but many require the full version... Someone who's working their way up to something that could be released commercially might not want to start off by dropping 400 bucks on a limited platform.

Anyway, these are just some thoughts I've had after observing a few threads in which there's invariably some sort of derisive, snarky, Darwinian contempt of 32-bit/freeware/hobbyists/SE plugins... Yes, there's a lot of crap out there, and yes, those who wish to make money from selling plugins should pay close attention to, and reflect, what their current and future customer needs are- but everybody has to start somewhere, and the cognoscenti (or successful developers, for that matter) should not be genuinely disturbed at the idea of large numbers of fresh faces appearing; the signal-to-noise ratio sorts itself out with time anyway

[MarlaPodolski]

The question is how long it makes sense to keep on using 32-bit. Are there even non-64-bit CPU's being manufactured still? Don't get me wrong, i don't see 32-bit dying for the next 10-15 years, but it WILL cease one day.

Well, this is the other silly scare tactic that some 64-bit advocates, with or without the 'derisive, snarky, Darwinian contempt of 32-bit/freeware/hobbyists/SE plugins', always try to worry and threaten those of us who are plenty happy with our 32-bit setups. Notice also that this scare tactic has also been used for years and has grown equally as old and tiring.

It might be safer to just say, "well, the world will end someday, and you won't be able to use those 32-bit items then!" It makes about as much sense.

There will always be a way to use 32-bit. One other benefit is that we 32 advocates can go back and still use those strange old early and often funky plugins without the hassle of bridging. Some few of those make sounds and fx that the newer 64-bit plugins cannot.

Why SE doesn't 'do' 64 and never will has been explained so many times before. It just is what it is. Time to let it go, and accept the fact that 32-bit users are just fine with their own perfectly working setups.

[chk071]

silly scare tactic

64-bit advocates

always try to worry and threaten those of us who are plenty happy with our 32-bit setups

Let's meet up, and fight about it, shall we?

But seriously, i don't think anyone cares if you or anyone else uses 32-bit or not. It's just that things are moving forward, not backwards. Fact of life. I don't think anyone will hinder you, or do all those other evil things you mentioned in your post, if you decide to stick to 32-bit for the next 20 years.

[BONES]

It's also not possible........SE is 32 bit/Win only.......

Actually, SE 1.2 is able to do 64 bit and from that you can make a Mac compatible version. I have no idea how well it all works, I haven't touched SE in several years, but it is supposedly doable with the latest betas.

[BONES]

The advantage is if you're running a 64 bit DAW on a 64 bit system (and really why wouldn't you) running 32 bit plugins requires the use of a Bit Bridge when in some cases brings added cost, stability issues, and/or performance hit.

Clearly you have answered your own question. I don't use a 64 bit set-up because too many of the plugins I rely on are 32 bit (my own SE synths and effects). If you don't want "added cost" or "stability issues", it makes perfect sense to stick with 32 bit as the benefits of going to 64 bit are negligible for many of us.

All the plugins I use on my studio system have 64 bit versions. I don't see any reason not to use them......

And yet here you are complaining because going to 64 bit means you can't use a particular plugin. Again, isn't that a reason to stay on a 32 bit set-up, rather than getting stuck into the developer for not doing what you want him to?

[whyterabbyt]

AFAIK OP-X Pro is based on custom modules written in C++ and SE is mostly used for graphics. This is why i do not understand that the developer should not be able to do a native 64-bit plugin.

Well, perhaps if you were to replace 'SE is mostly used for graphics' with something closer to the actual situation ie 'SE is mostly used for all the stuff that happens between the DAW and the audio processing code, from audio to MIDI to automation to preset handling, as well as all user-interaction right down to recognising when someone presses a mouse button' then you might not have raised a strawman for yourself. You're dismissing the fact that the bit that SE does is actually pretty damn significant, especially when in a native version it would probably have to be able to encompass multiple operating systems, multiple DAW standards, and multiple differences as to how DAWs interpret those standards.

Its decidely non-trivial, one reason a lot of native-code developers use something like JUCE, which, like SE provides a great deal of that infrastructure already. Of course JUCE costs a minimum of £400, 8 times what SE costs, assuming you only want to make one product ever. Its £700 for more than one. (Yes, you can use it for free, but you have to give away your code, not exactly something something commercial plugin developers seem to want to do.)

And of course porting something built in SE to something in C++ is in itself a significant task, even for a skilled programmer. SE, like most visual programming audio languages, actually works quite differently from a regular programming language. SE gives you control over event-driven nodes which 'seemingly' do constant processing of data and are connected together in an unstructured graph with data being shuffled through all sorts of serial and parallel connections 'simultaneously'. In a native programming language, you dont have the events, the nodes, the constant processing, the graph, anything to shuffle data, or those serial and parallel connections. You'd have to replace all of that yourself. It'd probably be easier to start from scratch, although of course that hardly renders it a trivial undertaking.
And the audio part is the easy side. Read some threads where people complain about plugin bugs; a tiny fraction of them will be about the audio side, the rest turn up in the host and user interaction because that's the hard part to get to work. Processing audio is easy in comparison (though good DSP is hard, but because math, not because code.)

This seems to be another one of those threads where a bunch of non-programmers handwave away the complexity of something they have no knowledge of. But yes, I do know this is KVR, where all plugin development is seen as trivially simple stuff, and all developers are lazy, incompetent, greedy imbeciles who know nothing about synths or music. In fact I personally dont doubt that many SE developers are not skilled enough in C++, the VST and AU specs and all of the stuff Ive mentioned to replace SE in their code, because that's a lot of hard stuff to have to be significantly skilled in. It doesnt magically become easy because people who dont actually understand what's involved think its easy.

[Halma]

AFAIK OP-X Pro is based on custom modules written in C++ and SE is mostly used for graphics. This is why i do not understand that the developer should not be able to do a native 64-bit plugin.

Well, perhaps if you were to replace 'SE is mostly used for graphics' with something closer to the actual situation ie 'SE is mostly used for all the stuff that happens between the DAW and the audio processing code, from audio to MIDI to automation to preset handling, as well as all user-interaction right down to recognising when someone presses a mouse button' then you might not have raised a strawman for yourself. You're dismissing the fact that the bit that SE does is actually pretty damn significant, especially when in a native version it would probably have to be able to encompass multiple operating systems, multiple DAW standards, and multiple differences as to how DAWs interpret those standards.

Its decidely non-trivial, one reason a lot of native-code developers use something like JUCE, which, like SE provides a great deal of that infrastructure already. Of course JUCE costs a minimum of £400, 8 times what SE costs, assuming you only want to make one product ever. Its £700 for more than one. (Yes, you can use it for free, but you have to give away your code, not exactly something something commercial plugin developers seem to want to do.)

And of course porting something built in SE to something in C++ is in itself a significant task, even for a skilled programmer. SE, like most visual programming audio languages, actually works quite differently from a regular programming language. SE gives you control over event-driven nodes which 'seemingly' do constant processing of data and are connected together in an unstructured graph with data being shuffled through all sorts of serial and parallel connections 'simultaneously'. In a native programming language, you dont have the events, the nodes, the constant processing, the graph, anything to shuffle data, or those serial and parallel connections. You'd have to replace all of that yourself. It'd probably be easier to start from scratch, although of course that hardly renders it a trivial undertaking.
And the audio part is the easy side. Read some threads where people complain about plugin bugs; a tiny fraction of them will be about the audio side, the rest turn up in the host and user interaction because that's the hard part to get to work. Processing audio is easy in comparison (though good DSP is hard, but because math, not because code.)

This seems to be another one of those threads where a bunch of non-programmers handwave away the complexity of something they have no knowledge of. But yes, I do know this is KVR, where all plugin development is seen as trivially simple stuff, and all developers are lazy, incompetent, greedy imbeciles who know nothing about synths or music. In fact I personally dont doubt that many SE developers are not skilled enough in C++, the VST and AU specs and all of the stuff Ive mentioned to replace SE in their code, because that's a lot of hard stuff to have to be significantly skilled in. It doesnt magically become easy because people who dont actually understand what's involved think its easy.

Amen! This sums pretty much up what developing native VSTs from scratch is all about. And its not about the dev who is not willing to change but about people who dont wanna use 32bit stuff anymore.

[chk071]

AFAIK OP-X Pro is based on custom modules written in C++ and SE is mostly used for graphics. This is why i do not understand that the developer should not be able to do a native 64-bit plugin.

Well, perhaps if you were to replace 'SE is mostly used for graphics' with something closer to the actual situation ie 'SE is mostly used for all the stuff that happens between the DAW and the audio processing code, from audio to MIDI to automation to preset handling, as well as all user-interaction right down to recognising when someone presses a mouse button' then you might not have raised a strawman for yourself. You're dismissing the fact that the bit that SE does is actually pretty damn significant, especially when in a native version it would probably have to be able to encompass multiple operating systems, multiple DAW standards, and multiple differences as to how DAWs interpret those standards.

Its decidely non-trivial, one reason a lot of native-code developers use something like JUCE, which, like SE provides a great deal of that infrastructure already. Of course JUCE costs a minimum of £400, 8 times what SE costs, assuming you only want to make one product ever. Its £700 for more than one. (Yes, you can use it for free, but you have to give away your code, not exactly something something commercial plugin developers seem to want to do.)

And of course porting something built in SE to something in C++ is in itself a significant task, even for a skilled programmer. SE, like most visual programming audio languages, actually works quite differently from a regular programming language. SE gives you control over event-driven nodes which 'seemingly' do constant processing of data and are connected together in an unstructured graph with data being shuffled through all sorts of serial and parallel connections 'simultaneously'. In a native programming language, you dont have the events, the nodes, the constant processing, the graph, anything to shuffle data, or those serial and parallel connections. You'd have to replace all of that yourself. It'd probably be easier to start from scratch, although of course that hardly renders it a trivial undertaking.
And the audio part is the easy side. Read some threads where people complain about plugin bugs; a tiny fraction of them will be about the audio side, the rest turn up in the host and user interaction because that's the hard part to get to work. Processing audio is easy in comparison (though good DSP is hard, but because math, not because code.)

This seems to be another one of those threads where a bunch of non-programmers handwave away the complexity of something they have no knowledge of. But yes, I do know this is KVR, where all plugin development is seen as trivially simple stuff, and all developers are lazy, incompetent, greedy imbeciles who know nothing about synths or music. In fact I personally dont doubt that many SE developers are not skilled enough in C++, the VST and AU specs and all of the stuff Ive mentioned to replace SE in their code, because that's a lot of hard stuff to have to be significantly skilled in. It doesnt magically become easy because people who dont actually understand what's involved think its easy.

Great post, thanks for all that info. Tbh, i wasn't at all aware too that it's not that trivial, probably mostly because as a non-programmer, i don't quite know what a "framework" does exactly, so i can only guess sort of. I didn't know that JUICE is so expensive to use either (though it probably doesn't take too many sales to make up for that).

[Ingonator]

Staying with SE and 32-bit seems to be OK for free and lowe priced commercial synths but at the price range of OP-X Pro II (full price is 179$ and the current sale sems top end today...) having a native 64-bit plugin and also cross-platform (Win/Mac) seems to be a MUST HAVE (just IMO of course).

Anyway i had owned OP-X Pro in the past (until a few years ago) and am no longer interested as i have enough other synths (mostly 64-bit...) that could replace it.

[Cyforce]

I personally can`t understand why SynthEdit &(!) Flowstone aren`t 64-bit WinOS (and also MacOS) ready...

Just from a economic viewpoint, their product (doesn`t matter if SynthEdit or Flowstone) is only useful for WinOS 32-bit exports - which becomes with every new day a more dead area in the OS world.
Even if they have to offer a lot of work time to update their products to make them 64-bit/Mac -able - if they don`t their own product won`t run well in sales - because no one needs a product which has no use for the users....

And software like SynthEdit & Flowstone are concepted to create VSTs.... and if 32bit WinOS is the dead area - so is their developement software dead too... so why both are still not updated?

Even if it`s complex/complicated etc to make their source code/engine run for 64-bit/Mac - than create a complete new dev software with the same target. I think most people would be happy even if there old modules/project won`t work - that they have at least a new option for multi platfom export & creations.

Pretty sad... Flowstone user`s waiting for 2-3 years now for a reason-able update. 99$ for 12 months update service, but in 12 months nothing really useful had came out as update in terms of new features, performance improvements or new exportable OS platforms. Kind of money for nothing...

[fluffy_little_something]

I read that with synths 32 vs 64 bit does not really matter, anyway. 64 bit is only important for those who want an exclusive 64 bit system. But really, when the host has a solid bridge, why would people care whether the plugin is 32 or 64 bit?

With SE the problem is more that its sound is inferior to most good proprietary synths'. So whoever writes the 64-bit standard modules, should also improve them, not just port them. I think the sound of 32-bit SE synths is more of a problem than their being 32-bit.

[chk071]

I read that with synths 32 vs 64 bit does not really matter, anyway. 64 bit is only important for those who want an exclusive 64 bit system. But really, when the host has a solid bridge, why would people care whether the plugin is 32 or 64 bit?

There's some GUI issues with bridged plugins for example. I had some focus problems using a virtual midi keyboard with bridged plugins. Anyway, i agree that it doesn't make much of a difference if you're solely using plugins, but as has been said, if there's Kontakt or some oter sampler in play, you maybe will want to use all of your system's RAM, so it'd be better to use 64-bit.