From my frankly pathetic amount of experience with C and C++ I should think it has a lot to do with things like bit shifting, pointer arithmetic, old functions that are not 64-bit compatible, and addressing memory in general. If it were a simple matter of writing a script to edit the source code and then recompile, they'd do it. I suspect that some parts of the code could be converted like this. But some parts must have to be recoded entirely, and I guess they wouldn't know without going over every single line of the source code and checking manually. Since source code for a complicated app like audio processing will probably run into thousands of lines (if not tens of thousands) then I should think it's not something they can just do in an afternoon. 

sharke


From my frankly pathetic amount of experience with C and C++ I should think it has a lot to do with things like bit shifting, pointer arithmetic, old functions that are not 64-bit compatible, and addressing memory in general. If it were a simple matter of writing a script to edit the source code and then recompile, they'd do it. I suspect that some parts of the code could be converted like this. But some parts must have to be recoded entirely, and I guess they wouldn't know without going over every single line of the source code and checking manually. Since source code for a complicated app like audio processing will probably run into thousands of lines (if not tens of thousands) then I should think it's not something they can just do in an afternoon. 

I absolutely agree with you, and a gigantic number of audio programs are written in C, by design, and for lots of reasons it is not trivial to not only just re-code, it would require some major redesign as well.  I spent a couple of years up in Boston on a computer project for the State motor vehicle agency, and they continue to use C for efficiency's sake. which I would imagine is certainly a factor in choosing a language for something as intricate and performance-demanding as audio processing.  And, C makes you do your own cleanup, deleting things when you are done with them and you have to do your own pointer management, so things like memory leaks and hard to debug errant branches are quite tricky to get right.


That being said, it has been a long long time for some of these plugins, and it seems like it shouldn't take years - I guess they either do not have the programming and/or financial resources, or some middle-management zero has decided it is not a proper spending of company development funds to invest in switching to 64-bit.


Bob Bone

The iLock thing does make sense, one of the plug-ins in question that I have on my system uses it.

backwoods


Well Flux released a couple today and said the rest should be done in Q1. Does algorithmix need iLok?

Yeah, Flux said they're quickly working on it. Algorithix said they're working on it, but getting responses from the maker of probably the most expensive Linear-Phase EQ has not been terribly fast. They do, however have an easy, old-school FTP way of accessing updates which is cool.  But they don't use iLok; they use Syncrosoft--just another dongle...

For everyone else here, yep, it does take a lot of re-coding to convert to 64-bit, much like how Waves has to re-code plug-ins for TDM support. I'm guessing this has a lot to do with the development tools and API's used to connect to for 64-bit processing (not the Audio company, btw - Application Programming Interface (API)).

iLok suffers from the same problem, I believe. But I will state loudly, it's their own fault. iLok peeps thought they had a decent idea and everyone would quickly adopt it. Oh how wrong they were! It was a terrible idea from the start. The premise was fine, but the result was "iffy" at best, and one UGLY dongle to boot! (the earlier dongle, that is). Still, some VST makers use it, and that's fine. But I bet they're mad as hell about having to recode for it.

Bob Bone : "That being said, it has been a long long time for some of these plugins, and it seems like it shouldn't take years - I guess they either do not have the programming and/or financial resources, or some middle-management zero has decided it is not a proper spending of company development funds to invest in switching to 64-bit."

It's quite possible (likely ?) that the guy/gal who wrote the original driver no longer works at the company and nobody else has a clue as to what s/he did. Personally, I'd prefer a rewrite under those circumstances, but it wouldn't get done in an afternoon.

Documentation ? What documentation ?

Paul P


Bob Bone : "That being said, it has been a long long time for some of these plugins, and it seems like it shouldn't take years - I guess they either do not have the programming and/or financial resources, or some middle-management zero has decided it is not a proper spending of company development funds to invest in switching to 64-bit."

It's quite possible (likely ?) that the guy/gal who wrote the original driver no longer works at the company and nobody else has a clue as to what s/he did. Personally, I'd prefer a rewrite under those circumstances, but it wouldn't get done in an afternoon.

Documentation ? What documentation ?

We don't need documentation - we are in a paperless office these days. :)


I would imagine that turnover and daunting challenge are quite probable, and yet there i still a market for some of the better ones.  With the relatively recent hard times for retaining jobs out there - it would seem that there might be some folks qualified to review and/or rewrite some of these for 64-bit.


Then again, C programmers are getting a little hard to come by, I theorize.


Bob Bone

We don't need documentation - we are in a paperless office these days. :)


I would imagine that turnover and daunting challenge are quite probable, and yet there i still a market for some of the better ones.  With the relatively recent hard times for retaining jobs out there - it would seem that there might be some folks qualified to review and/or rewrite some of these for 64-bit.


Then again, C programmers are getting a little hard to come by, I theorize.


Bob Bone

Good thread. I've programmed primarily in the embedded world...


I'd have to assume that any delay in bringing 64bit plugins to market has to do with labor issues. Plugins are a boutique business - I'll bet most business have only a couple of programmers and that's it. Sure, it'd be great to have a large staff of programmers, but the way businesses are structured today, marketing and management suck up the lions share of revenue.