Korg updates its Legacy Collection with a new Arp Odyssey emulation

[EsiGui]

This will probably get lost in the sea of comments, but I just compared the Odyssey CPU usage to Repro 5 in Ableton. Repro is at 8 voice with unison and the Odyssey is at 16 and 16. I'm running Sierra on a 2.9GHz i5 Macbook Pro from 2016. Repro reads just over 50% with multicore off, just over 30% with it on, and the Odyssey reads just under 30%.

[ENV1]

I don't know what is more 'self absorbed', expecting people to deal with changes in technology, or expecting to be catered to because you refuse to change.

To put it the least offensive way possible: The problem is with your thinking. With the fact that you choose to think in a certain way and then treat it as though it were some 'superordinate truth' or something. Not that i expect you to even understand what i mean, youre probably too deeply indoctrinated into throwaway consumerism for that. But the fact is that there is no rule that states that everytime a new version of something comes out, support for the predecessor HAS to be ceased. If this is being done then its purely by choice, not because anyone is pointing a gun, which means that technically support for 32bit could continue forever, and if somebody chooses not to support it then that is an arbitrary choice theyre making for whatever reasons they think theyre having, not something that is required by a law or some other inevitable circumstance.

You can still use your 32 bit plugins on a 64 bit system if you use a bit bridge.

Its funny how this is always being presented as 'the' solution to 32bit users, yet when a plugin comes out in 32bit-only you can hear the wailing and gnashing of teeth echoing all around the globe.

(And thats putting it mildly. A lof of devs had to listen to stuff thats downright offensive.)

If you expect new plugins to work with your 15 year old DAW/computer combo without a bit of work on your end, forgive me if I think you are the one with 'self-absorbed' issues.

Like i said. Thinking.

There is nothing that stops you from adopting a different attitude like 'retaining backward compatibility is good so lets do that as long as technically possible'.

You only choose not to.

Needless to say that you will probably change that attitude in a hurry next time you are affected.

[chk071]

You can still use your 32 bit plugins on a 64 bit system if you use a bit bridge.

Its funny how this is always being presented as 'the' solution to 32bit users, yet when a plugin comes out in 32bit-only you can hear the wailing and gnashing of teeth echoing all around the globe.

(And thats putting it mildly. A lof of devs had to listen to stuff thats downright offensive.)

That's because, in my experience, bridging rarely works without issues (GUI related, or plugins losing focus etc., all sorts of things), and, because bridging requires more CPU than running a plugin natively. It isn't THE end it all solution. Native 64-bit is.

Not everyone knows that there is a thing called 32-bit-bridge either. And, to be frank, i think, in 2018, with 64-bit OS's and hosts available since over 10 years, devs should provide native 64-bit versions. If they don't, they shut the door for a large crowd of potential customers. Actually, the vastly bigger crowd, because, 32-bit only is surely merely used by a low percentage of people (Yes, yes, hate on me now, 32-bit misfit loners ). After all, it has a reason why some devs even don't offer 32-bit versions of their plugins and hosts anymore.

[Harry_HH]

You can still use your 32 bit plugins on a 64 bit system if you use a bit bridge.

Its funny how this is always being presented as 'the' solution to 32bit users, yet when a plugin comes out in 32bit-only you can hear the wailing and gnashing of teeth echoing all around the globe.

(And thats putting it mildly. A lof of devs had to listen to stuff thats downright offensive.)

That's because, in my experience, bridging rarely works without issues (GUI related, or plugins losing focus etc., all sorts of things), and, because bridging requires more CPU than running a plugin natively. It isn't THE end it all solution. Native 64-bit is.

Not everyone knows that there is a thing called 32-bit-bridge either.

Bridging may not be the optimal situation, but I´ve got about twenty 32 bit plugins from 5 different developers, bridged to my 64 bit DAW via the jBride, never had any issues, and if the bridging charges the CPU, its so little I can´t measure it. The only issue with the bridged plugins, has been my old ver. 8 Waves plugins, and that´s not because the jBridge, but because the Waves installer/manager sometimes messes the Waves shells, of different versions located in the same computer.
I salute J because of his great product.

[wagtunes]

ENV1, you used the phrase "as long as technically possible."

Let me explain something. Anything is technically possible. We have the technology to do just about anything you can conceive of. So what you're essentially saying is, forever.

So let me ask you a question. When does it end?

If we adopted this philosophy of backward support from the beginning of time, we'd still be supporting MS-DOS applications right now. Should we?

Where do we draw the line? When do we draw the line? Because technically, anything is possible. We have DOS emulators right now that can play old DOS games. We've got sites dedicated to old Atari games from the 70s. In fact, I've played some of them from time to time when I had nothing to do. Pitfall II is still my all time favorite.

But where does it end? Because technically, we can support 32 bit forever. It never has to end.

Should we?

If that's the case, then we should have never abandoned Windows 95 or MS-DOS. They should still be supported today.

I mean, you can't have it one way and not the other.

If you're saying we should support 32 bit forever, then by rights we should go back to supporting Windows 95 and even MS-DOS.

You know what they say about what's good for the goose is good for the gander.

Your thoughts?

[chk071]

You can still use your 32 bit plugins on a 64 bit system if you use a bit bridge.

Its funny how this is always being presented as 'the' solution to 32bit users, yet when a plugin comes out in 32bit-only you can hear the wailing and gnashing of teeth echoing all around the globe.

(And thats putting it mildly. A lof of devs had to listen to stuff thats downright offensive.)

That's because, in my experience, bridging rarely works without issues (GUI related, or plugins losing focus etc., all sorts of things), and, because bridging requires more CPU than running a plugin natively. It isn't THE end it all solution. Native 64-bit is.

Not everyone knows that there is a thing called 32-bit-bridge either.

Bridging may not be the optimal situation, but I´ve got about twenty 32 bit plugins from 5 different developers, bridged to my 64 bit DAW via the jBride, never had any issues, and if the bridging charges the CPU, its so little I can´t measure it. The only issue with the bridged plugins, has been my old ver. 8 Waves plugins, and that´s not because the jBridge, but because the Waves installer/manager sometimes messes the Waves shells, of different versions located in the same computer.
I salute J because of his great product.

TBH, i stay away from plugins and developers who don't offer a 64-bit version. I won't buy the new Viper synth either, unless it becomes 64-bit at some point. And, i think it is the wrong direction either. The dev is waiting how the interest is to determine whether it's worth to do a 64-bit version, but, interest won't be very high when he's not offering a 64-bit version... kind of a Catch-22 thing.

I do understand his reasons in that case though, he's familiar with Flowstone, codes in Ruby, which is the native language in which Flowstone modules are coded, so, it will be quite an effort to port it into a C++ framework, or even code it in C++ natively. Still won't buy it, just to bridge it into my 64-bit DAW.

[Harry_HH]

You can still use your 32 bit plugins on a 64 bit system if you use a bit bridge.

Its funny how this is always being presented as 'the' solution to 32bit users, yet when a plugin comes out in 32bit-only you can hear the wailing and gnashing of teeth echoing all around the globe.

(And thats putting it mildly. A lof of devs had to listen to stuff thats downright offensive.)

That's because, in my experience, bridging rarely works without issues (GUI related, or plugins losing focus etc., all sorts of things), and, because bridging requires more CPU than running a plugin natively. It isn't THE end it all solution. Native 64-bit is.

Not everyone knows that there is a thing called 32-bit-bridge either.

Bridging may not be the optimal situation, but I´ve got about twenty 32 bit plugins from 5 different developers, bridged to my 64 bit DAW via the jBride, never had any issues, and if the bridging charges the CPU, its so little I can´t measure it. The only issue with the bridged plugins, has been my old ver. 8 Waves plugins, and that´s not because the jBridge, but because the Waves installer/manager sometimes messes the Waves shells, of different versions located in the same computer.
I salute J because of his great product.

TBH, i stay away from plugins and developers who don't offer a 64-bit version. I won't buy the new Viper synth either, unless it becomes 64-bit at some point. And, i think it is the wrong direction either. The dev is waiting how the interest is to determine whether it's worth to do a 64-bit version, but, interest won't be very high when he's not offering a 64-bit version... kind of a Catch-22 thing.

For me all the 32 bit plugins are historical relics, plugins which I have had very long time, which are great plugins but not updated to 64 bit. A couple of examples: TbT Tapestop, URS 1975. Special case: Waves 32 bit plugins.

[tristan-]

Honestly, I can't wait for an updated hi-res GUI for the Wavestation.

[ENV1]

Actually, the vastly bigger crowd, because, 32-bit only is surely merely used by a low percentage of people

I still havent seen any proof of that.

If you can point me (and everyone else who is interested) to a credible source id appreciate that because we all know how good internet forums are at repeating false information, i.e. 'everyone said it so i assumed its probably true'.



PS: The forum just let me know that new comments were posted while i was typing.

I will be back to continue the discussion later, i have to leave in 10 minutes.

[chk071]

Actually, the vastly bigger crowd, because, 32-bit only is surely merely used by a low percentage of people

I still havent seen any proof of that.

If you can point me (and everyone else who is interested) to a credible source id appreciate that because we all know how good internet forums are at repeating false information, i.e. 'everyone said it so i assumed its probably true'.

3 of the biggest DAW's are 64-bit only by now, and that surely doesn't happen based on speculations, they collect usage data, they collect download data. There are a few plugins now which are 64-bit only too, just like the Korg Arp Odyssey. Really, you gotta be pretty deluded to think there's a massive crowd of people still using 32-bit only by now.

And, to which "reliable source" do you expect me to point you? There is no reliable source. That's an absolute desperate argument. Just take a look around, and use some common sense. I don't know if you're really willed to, though. It appears to me as if you're advocating 32-bit software with an almost fundamentalistic zeal. Just because YOU use 32-bit only.

[tristan-]

Very small amount of paid plugins are not available in 64 bit form. mostly discontinued ones.
Freebies - ofcourse there are. but there's Jbridge for that, although far from perfect.

I can't see any point of continued support for 32bit in 2018. Seriously, what's the point?

When I hear the word 32 bit, I think of - Tau Pro, Vanguard, Albino, Bionic Delay (this one is great though!) - I don't think anyone mentioned any of those in KVR over the last year.

[egbert101]

<delete>

[Jace-BeOS]

Regarding the change from 32-bit to 64-bit and talking about keeping DOS and Windows 95... There are just some points in development that need to happen and we need to move on from them. Windows 95 was garbage, but it was better garbage, from an end-user's experience, than the garbage of WinDOS, so it had to happen.

What's unique about products released then is the direct hardware access that the "modern" NT kernel blocks. There's not much of said software that I'm aware of and most of it is indeed in audio. Access to old software can be, and is often, solved with virtualization. The hardware that software of that era was made for was slow enough that virtualization isn't too slow. Compatibility is the question. DOS has its own virtualization environments, as mentioned before me. This is all mostly for old games and manufacturing equipment that no one wants to change to modern interfaces. The old COM port is still valued by certain engineering needs... but this is where computer industry engineering needs to catch up: If there's a legit need not being met by modern hardware and operating systems, then something needs to change to deal with that.

I want stuff to last me a while, definitely, since I'm poor!! However, I don't think we should hold off on technical advancements for the sake of ensuring every old piece of software/hardware works indefinitely.

32 to 64 bit was a valuable change in architecture, most notably for greater memory usage. There are ways to get around it but they're inelegant. Continuing to support 32-bit code on a 64-bit system doubles your code management and support scope. This is problematic for small software but very serious for huge products like operating systems that have to support everyone else's products.

This change was necessary. The same for when we went from 16-bit to 32-bit (I remember it). That transition was much faster as there was a much smaller installation of computers in the world and the bulk of them were not consumers.

The 64-bit change was very slow because it had to move a much larger number of people and businesses. People needed to be able to adapt. Still, both of these changes made sense and needed to be done. There's probably not going to be a 128-bit architecture, as mentioned.

Backwards compatibility is to allow people to move on, not to give them indefinite support. When it's just normal technical progress, people should upgrade eventually (see caveat below). At some point, developers want to stop maintaining this transitional stuff that's just there for people who haven't upgraded to modern architectures.

The caveat:

Capitalism.

The changes that push computer sales on the consumer end are mostly not about technological advancement. Right now, computer technological advancement in general is at a slump, for reasons of physics and practicality (that's covered in other places, don't expect me to expand on it). But computer manufacturers want to keep selling their product. Even if this were all, companies could survive just fine. But we have public ownership and Wall Street. The demand for perpetual growth is not sensible in any realm or context.

All computer change is currently driven by the larger sales market: the end consumers. NOT science and technology; not content-creator studios.

The solution to a company's shareholders demanding better numbers tends to be to ship new product, faster than the previous, with marketing of "more new features" to convince people to buy it. Even though technological advancement has slowed, new features are still coming at an onslaught pace, and the value of them is greatly diminished.

These companies have spent the first three decades of computing getting addicted to the notion of quick overturn of hardware, so it's not a new thing to them to fluff up the marketing. They could keep up with Wall Street stupidity for quite a while, but then we reached saturation and that means nothing to Wall Street types. Since CPU speed advancement has slowed, they've had to invent new causes to perpetuate the notion "it's obsolete after five years". Worse, they've accelerated it to "it's obsolete after three years". Which computer company will pioneer a subscription model for computer hardware to push this further? We already have corporations leasing hardware but I'm sure we can make this even more wasteful! :-p

The companies who sell both hardware and software are the biggest culprits here because they can push this process on both ends. Instead of controlling it for the best interests of their customers, they control it for the best interests of their shareholders. This is a systemic problem and no company will avert this stupidity if it means exposing them to failure compared to other companies willing to keep playing this game of inevitable failure (because they'll make money in the mean time and surely someone else will come up with a scheme to fix this one, later).

Yes, I'm referencing Apple here as one of the companies most pushing obsolescence. They're not alone. Windows won't save you in the end because Microsoft has recognized some of Apple's methods of success and is getting more into hardware. The time of Windows being an unchanging platform ended with automatic updates.

Both companies will use "security" as the key excuse to push you to keep "up-to-date".

"We need you to update to have the most secure system"...

...but I'm pretty sure we all know this is bollocks. If their focus was on security, they wouldn't constantly be upsetting the codebase to force new features in and sell it to you again and again. It's not about security any more than it was ever about bug fixing (and who here still believes that paying for the new version is going to fix your bugs?). It's about selling the product to you again. And then again. Repeat chorus. Surely you can't live without this new social networking feature!!

When these unnecessary changes are made, it affects the third-party software developers, who are even more a victim to unnecessary change than consumers (because they have to ensure their product works on the bleeding edge new system AND still works on the prior ones). They have to make a cut off point for sanity. It's some kind of balancing act to figure out how many customers and potential customers are on which platform. This is why developers like usage data.

It's often not just the one change they need to make, either, so maintaining old code starts to be like maintaining separate products for three to six platform variations, which also means keeping that many systems running. I'd personally would want to stop supporting hardware and operating systems I no longer used and not have six computers around just to validate my changes didn't break functionality on the last three systems... (maybe just the last two... well, maybe just the last one...).

Changing one thing often means changing others (change bitness? Change compiler, API, middleware...). Some developers don't want to bother because it seems valueless to them to do it. I wouldn't want to be a developer. I know how demanding I am on computer industry products and I know how dependent developers are on the rest of the industry (third-party developers cannot fix OS or hardware bugs).

32-bit to 64-bit isn't the only thing developers have been lagging on. There's also high-PPI. High-PPI displays are kind of like 64-bit: it's a necessary change (this might take tech people with perfect eyes and a lot of acculturation to low resolution a while to understand). It should've happened sooner, too.

There's merit to change... just not the continuous change driven by Wall Street stupidity that results in people having a hard time (harder than ever) trying to do work on a consistent platform. If not for this forced obsolescence, people on older systems would feel more like three years behind, rather than being treated like they're a decade behind.

It doesn't help that the computer industry is still, after forty years, basically a child and ill-prepared for the reality of being ubiquitous.

[T11]

Please admins break out this 32 vs 64-bit to another thread.

[braj]

Man, I'm pissed Korg doesn't support my C64! Grr...

I agree, can we stop beating this dead horse already? I really hope Korg does the new versions well, as many have mentioned, the patch browsing in Odyssey is less than ideal, hopefully the others will be better.