The No.1 Website for Pro Audio
 All  This Thread  Reviews  Gear Database  Gear for sale     Latest  Trending
why are devs so behind on 64 bit?
Old 21st October 2013
  #1
why are devs so behind on 64 bit?

just curious as to why developers didn't see this coming. or if they did why didn't they do anything about it? its just frustrating that i have to choose between between using my systems full power or a plugin. lame
Old 21st October 2013
  #2
Lives for gear
 
login's Avatar
Choose better developers maybe?
Old 21st October 2013
  #3
Lives for gear
b/c it's a lot of work and they're busy


No... that's really the truth lol... just in a more blunt way. I don't write software but... if they are porting from 32bit to 64bit, it sounds like they essentially have to rewrite the code, which probably takes forever depending on who's doing it.
Old 21st October 2013
  #4
Quote:
Originally Posted by login View Post
Choose better developers maybe?
i choose the developers i can afford. and since i payed for it i think i have a right to criticize them.
Old 21st October 2013
  #5
Gear Addict
 

Cytomic, U-he. Valhalla DSP, DMG Audio all 64 bit and affordable
Old 21st October 2013
  #6
Lives for gear
 
EvilDragon's Avatar
Which devs in particular?
Old 21st October 2013
  #7
Lives for gear
 
kim olesen's Avatar
 

Quote:
Originally Posted by EvilDragon View Post
Which devs in particular?
Flux comes to mind.
Old 21st October 2013
  #8
Lives for gear
 
login's Avatar
Quote:
Originally Posted by rjo361 View Post
i choose the developers i can afford. and since i payed for it i think i have a right to criticize them.
In fact I believe that across all price ranges there are more "active" developers. Maybe something to keep an eye too.
Old 22nd October 2013
  #9
I've been waiting for Altiverb 7 for Windows (which is native 64bit) for....I can't remember how long I've been waiting.
Old 22nd October 2013
  #10
Gear Nut
 
rtownsend's Avatar
 

I developed for quite awhile (not audio plugins). For me personally, doing software tasks like converting from 32 to 64 bit (or 16 to 32 bit) is one of my least favorite things about programming. I think it'd be pretty easy to demotivate someone from doing this kind of work.
Old 22nd October 2013
  #11
Gear Addict
They are all eating cake. Simple.
Old 22nd October 2013
  #12
Lives for gear
 

Porting to 64 bits has to have been one of the most thankless tasks I've had.

It took an inordinate amount of time, just to in effect get back to where I was where I started, the same plugin with the same featureset, which seemed to work fine in bridges in the first place (so users didn't seem to really gain anything other than the comfort of not using a bridge)

Ironically apart from having to rewrite some assembler optimized sections, the actual "64 bit" part wasn't really an issue, Apple dropping various APIs when they went to 64 bits was.

It's very hard to stay motivated in those circumstances.
Old 22nd October 2013
  #13
Gear Addict
 

Having a good knowledge about software development myself Im surprised to hear it is not just a recompile of the code with another compiler.
Old 22nd October 2013
  #14
Lives for gear
 

Quote:
Originally Posted by Jon Hodgson View Post
Porting to 64 bits has to have been one of the most thankless tasks I've had.

It took an inordinate amount of time, just to in effect get back to where I was where I started, the same plugin with the same featureset, which seemed to work fine in bridges in the first place (so users didn't seem to really gain anything other than the comfort of not using a bridge)

Ironically apart from having to rewrite some assembler optimized sections, the actual "64 bit" part wasn't really an issue, Apple dropping various APIs when they went to 64 bits was.

It's very hard to stay motivated in those circumstances.
All of that and then customers want the update for free.
Old 22nd October 2013
  #15
Lives for gear
 

Quote:
Originally Posted by EMU10K1 View Post
Having a good knowledge about software development myself Im surprised to hear it is not just a recompile of the code with another compiler.
Much of it is, however the bits that aren't can take a disproportionate amount of time.

As I said before, mostly it's not the "64 bit" part per se, rather it's the other things that were changed at the same time, for example Apple dropped Carbon, which meant that GUI code that had been working perfectly well since OS9 had to be largely rewritten, also calling conventions changed so any assembler had to be modified accordingly (I also took that opportunity to increase optimizations in that code).

Most of the issues were due to Apple, they're far more fond of changing stuff and loading work onto developers than Microsoft.
Old 22nd October 2013
  #16
Tui
Gear Guru
 
Tui's Avatar
Quote:
Originally Posted by Jon Hodgson View Post
Most of the issues were due to Apple, they're far more fond of changing stuff and loading work onto developers than Microsoft.
They suffer from the "different is better" bug, like much of the tech world.
Old 22nd October 2013
  #17
Gear Nut
 
rtownsend's Avatar
 

Quote:
Originally Posted by Jon Hodgson View Post
Porting to 64 bits has to have been one of the most thankless tasks I've had.

It took an inordinate amount of time, just to in effect get back to where I was where I started, the same plugin with the same featureset, which seemed to work fine in bridges in the first place (so users didn't seem to really gain anything other than the comfort of not using a bridge)

Ironically apart from having to rewrite some assembler optimized sections, the actual "64 bit" part wasn't really an issue, Apple dropping various APIs when they went to 64 bits was.

It's very hard to stay motivated in those circumstances.
And when you got done, you tested it under Windows 7, Windows 8, OSX, etc with VST, AU, AAX, etc. And the time estimate that management required you to make was accurate, right? And they weren't upset that it took longer than your estimate, right? And the users were extremely thankful that the 64-bit version was released, even though everyone considered it late?
Old 22nd October 2013
  #18
Registered User
Quote:
Originally Posted by EvilDragon View Post
Which devs in particular?
Not that I'm complaining, the plugs are free and awesome but I'd love Bootsy to go 64 bit. They're the only plugs I really miss along with Sampletron. Very disappointed with IK over that
Old 22nd October 2013
  #19
I write some software myself (not for audio) and understand porting with different sets of APIs is a pain. BUT, by NOT doing it quickly, the developer is losing some potential buyers, as well as losing some loyal customers. If I'm a head of that re-porting team, I'll push everybody to work 70hrs/week, and get it done ASAP. It should be the top priority to keep the customers.
Old 22nd October 2013
  #20
No idea what the situation's like in Mac OS, but in the Windows world, converting a code base from 32-bit to 64-bit was pretty quick and painless, IF:
  • You followed Microsoft design guidelines that had mostly been in place by the time Win XP was released.
  • You used Microsoft's SDKs, compilers, and IDE (and coded in C/C++).
  • You had adequate resources for regression testing. (Making sure the changes you made didn't break anything.)

We're primarily a C++ Windows shop and it took two of our developers (I was one of them) three weeks to convert our entire Windows product line (several million lines of code, and several dozen drivers and binaries) from 32-bit-only to 64/32-bit a few years ago. We were already mostly following design guidelines, and we were already using up-to-date SDKs that included 64-bit support and data types. We just had to look for places where people were doing naughty things with pointers or making assumptions about the size of certain data types. After the engineering work we had a team of test engineers do heavy testing for a couple of weeks.

This was a best-case scenario.

Some bigger developers have huge code bases that were built on old SDKs or with old tools that existed before 64-bit development (in this context) was a thing.

Some smaller developers have day jobs, and have limited resources (often it's just one guy doing everything), and even if the actual engineering work is trivial, the testing burden can be quite big. No one wants to release an update to an existing product that subtly breaks several features that used to work.

Also, developers who actively support multiple platforms (Win/Mac, etc) might be stuck with tools or SDKs that didn't make the transition from 32-bit to 64-bit as easy as it was for people who solely target Windows.

I have no idea what kind of special libraries or tools plugin developers use, which may have complicated the issue for audio developers. And if any work needed to be done in Assembler, I can see that taking some serious time to address. But in general, if you didn't make too many assumptions about architectural aspects of your target platform, the actual act of moving from 32-bit-only to 32/64 was not that big a deal.

With Windows specifically, 64-bit actually introduced a few obstacles (primarily for people who weren't following Microsoft's design guidelines up til then), and 64-bit Win 7/Win 8 were more "locked down" than the 32-bit versions. This is probably more of an issue for DAW developers than plugin authors who don't do standalone support, but it added a fair amount of extra work for folks who weren't ready for it.
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump