DSP Robotics Support

Greetings all, loooooong time no see!

I heard from a customer when loading a 32bit VST al other 64bit VST's are operating on 32bit. Is this true?

If you can't tell whether it's true or not without asking - then it doesn't sound like 64bit makes that much difference then!

I'd be very surprised if that were correct. It that were required, then by extension, the host itself would probably need to run as 32bit as well, and I'm pretty sure that we'd all have heard about that. Doing some kind of wrapping on the "rogue" 32bit plugin, so that the rest of the architecture is isolated from it sounds much more like the way any sensible programmer would deal with the problem - and that is pretty much what all the sequencer developers seem to have described whenever I've ever ready anything about it.
It does seem likely thougn, that in order to get stuff out fast, a lot of developers did their own in-house 'wrapping' of their exisiting 32bit plugins when things went 64bit - crunchy on the outside but all soft in the middle kind of thing. So I think there is a little truth in the idea that not all 64bit plugins are really 64bit all the way through, so to speak.

trogluddite wrote:It does seem likely thougn, that in order to get stuff out fast, a lot of developers did their own in-house 'wrapping' of their exisiting 32bit plugins when things went 64bit - crunchy on the outside but all soft in the middle kind of thing. So I think there is a little truth in the idea that not all 64bit plugins are really 64bit all the way through, so to speak.

Thats all we'd need in FS to keep the 64bit wolf paclk from biting the hell out of us all the time.. so why don't they just create their own wrapper.. ?

Hey Trogluddite, how are you?

I am still on xp service pack 3, so I wouldn't know the difference. Sometimes I get asked if I will release my synths in 64bit, I just want to satisfy my customers.

AngularMomentum wrote:I get asked if I will release my synths in 64bit, I just want to satisfy my customers

Yes, I find it hard to keep my mischievious side under control sometimes! - and truly, all my experiences of Windows 7 and 64bit have left me seriously underwhelmed.

But I do understand that some people, like you say, have their income riding on keeping their customers satisfied, and that the VST capabilities of FS are well behind the times.
But I also think that people who are in that position need to ask themselves if they are really using the right tool for the job, and whether they truly believe that FS will ever be the right tool for the job.

I don't mean that to sound like I'm dissing FS, because I think it's an amazing bit of kit, and I love using it - it suits my personal needs better than anything else by a long chalk. IMHO the target audience is hobbyists, education, rapid prototyping, and small scale engineering where the expense of commissioning custom software is prohibitive. Its biggest strength is that it puts programming power in the hands of people who otherwise would be excluded from making their own software due to lack of training, expertise, resources or time. To expect it also to be a professional VST environment, able to emulate anything possible with the VST SDK and C++, is asking rather a lot, I feel.

DSPr have their own business and marketing plan, it is up to them whether they think the programming effort to support a small number of specialist users is cost effective, or makes good marketing sense. Maybe the VST devs will get what they require in the near future, and there is certainly no harm in lobbying DSPr to plug those holes - but that still won't change the fact that professional VST projects will be affected by decisions that are beyond the developer's control so long as a 3rd party development environment is used.
So the choice is whether to accept that fact, and whatever limitations come with it, or go down the VST SDK route in order to have more control over the available features.

I hope that doesn't come across as too negative or judgmental - I don't mean it that way; just trying to be pragmatic - and I am all in favour of seeing these features developed. But at the end of the day, DSPr are a pretty small concern with limited resources, and their success depends on appealing to as broad a range of customers as possible.

The former SM'ers have dominated the forum just recently, but there are also other users out there not remotely interested in what we do - if they are not so vocal here as we are, maybe it is because they are the satisfied majority - the 'bread and butter' customers ensuring the company's viability because the balance of features suits them perfectly?
Or maybe they just find us lot too rabid and obsessive and we're scaring them all away!

So are you saying that
-VST customers are not important to dspr?
Personally I don't think there's that may robotics guys here. I could be wrong, but I think that the bread and butter for FS right now, IS the VST devs.

-That keeping up with the latest technology is not important to them (DSPR)?
I don't know if its important to them or not, but its important to their users, so for that reason it should be important to them.

-That we as VST users should just STFU and be happy with what we got?
Wrong Troggie. If it were not for the users speaking up and saying what they want and need then this software probably would not be what it is today. You are doing no one any favours by STFU and "Making do". That does not help DSPR, it does not help the current user base, and it does not help future users. So instead of worrying about the few customers who apparently keep the company afloat, (we don't know that for a fact they do) a company should worry about the whole user base and provide them with what they want and need.

Just my 2 cents.

@trog

right tool for the job? YES!!

SM and FS are great tools for making VST's and have success with it (as I know from experience)

But at the same time working now in FS on a cool device control project:
1. FS-built remote control app on a windows 8 x86 based Asus Vivotab Smart sends data over Wifi to a server PC
2. The FS built server program controls 16 channel USB connected relais for switching audio between 5 speakers.
3. FS Server also sends data to cheap ICS-1000 home automation station to control 5 lamps wirelessly.

All this is synced with soundtrack played by FS server with FS mp3 player, to make an orchestrated show of sound and light, controlled by a tablet. Might post more details later.

My point is: FS can do both perfectly. Audio and device control don't have to be conflicting with each other, regarding improvements to FS, discussions on the forums etc. They can be combined in perfect synergy to make something unique!

CC

Hi all,

The 64-bit quest for Windows is NOT being driven by VST developers and their clients; it is and has been driven for many years already by Microsoft, responding to hardware developments many years ago by Intel. As a historical note, the very first Platform SDK CD that I ever received from Microsoft (circa 2000) had 64-bit stuff on it.

The pressure to get rid of 32-bit programming support is going to build and build until it cannot be resisted any more. For software companies who want to be in business in (say) ten years, the question is not "if?" but "when?"

VST3, however, may be subject to the question of "if?" Personally, I liked VST3 better due to the re-organization of things. But others didn't, so ????

Regards
Dave Clark

OK, OK, I hold up my hand.
I am mostly in agreement with what you are all saying, and was rather playing "devil's advocate" - what we feel we need to make FS a top VST development platform, and our reasons and justifications for those requirements, have been rehearsed, rewound and replayed more times than I've had hot dinners. So my apologies, I just could not resist throwing in a few counter-arguments, partly for a bit a light relief from listening to a stuck record - but also because moving to FS and Ruby has thrown up some whole new issues around VST exports that may or may not have to take precedence if they are more "mission critical". Given that we probably can't see all our demands met at once, I think it useful to debate their relative importance and present the dev's with what we think our priorities are, rather than endlessly repeat a list of demands of which they are already well aware.

VPDannyMan wrote:-That we as VST users should just STFU and be happy with what we got?

I quite understand your reaction, but I was very careful not to say that.
You are right, the dev's do value the VST crowd, and would love to see FS become the "go to" VST development environment that we all want it to be.
We are lucky now to have at least some dialogue with Malc, something we sorely missed during the last few years of SM. And he has told us directly that these things are all issues that DSPr want to resolve, and even admitted his own frustration at not being able to implement them all. I've had quite a bit of contact with him recently, highlighting bugs, testing fixes etc. - and I trust what he is saying, he has listened, and is working towards those goals as quickly is he is able to.
But, if those things were easy they would surely have been fixed by now - and there's a lot of catching up to do. So,yes, we should keep these issues at the forefront of the dev's mind, and post concrete examples of where they cause us problems - but at the same time, we are going to have to be patient.

VPDannyMan wrote:Personally I don't think there's that may robotics guys here.

Tricky one to assess purely from forum postings. I work for a similar small company - the vast majority of our customers are large educational institutions and small engineering companies, but we also attract many hobbyists. The hobbyists totally dominate our forums, while the 'professionals' barely use them at all, preferring to use 'direct' customer support.
Of course, you could well be right, I really have no idea - but getting a core of multi-seat users who write the software into their curriculums, and so lock themselves into the system, is surely something that DSPr are aiming for - hence the slow adoption of VST into FS, while they made the software suitable for opening up those markets.

Yes trog, No doubt we have to be patient and supportive by posting ideas and suggestions to fixes. These are not "demands", and should not be taken as demands from the devs, they are ideas.