64 bit question

Now THAT'S a fine question.

I am a programmer, and often wondered the same thing.

Bob Bone

I ...WAS... a programmer, and I have no idea. A network/Unix/systems/ programmer from 1968-1999.

It seems to me to be a switch on a Make File and then look at the errors.


But what do I know, things were simpler n 1999.

The guy who designs the Kush audio plugs said in his case the porting to 64 bit was not difficult but iLok protection for 64 bit plugs is extremely difficult and only a handful of guys in the world can do it.

Soundtoys is a good example- if 64 bit plugs weren't developed simultaneously and require iLok apparently it can be difficult to get it all to work. It has taken Flux Audio who make some super-expensive plugins until today to start releasing them in 64 bit- again, ilok protection. It took Waves a long time to release 64 bit versions and when they did they ditched iLok. ProTools- 32 bit, iLok.

Out of curiosity- which companies are you waiting on?

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

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

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.

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