DUNE 3 is now available!!

[cytospur]

You need to change settings from internal to host.

[AnX]

that reminds me, i must change the clock in my van to BST

[gondii]

You need to change settings from internal to host.

ahhh thanks a lot!!

[nucleox]

Yes it is more work. But it is not that much more work, as reported by numerous developers.

But it is more work regardless of how much or how little.

That time could be spent on making a new GUI for OBsession to fulfill the requests of other users both Mac and Win.

There is certainly no shortage of feature requests from other users so all you can do is hope your request is granted.

Oh well good luck we'll see what happens.

pretty simple, really; make one install for the intel code and the M1 code, as every other developer has done so far (well, everyone that has in fact created M1 code).

using a mac is like using a PC; it's a computer, runs software. we plug in a keyboard (or whatever) & make music. it's 2021, ridiculous to still be doing that 'mac vs pc' thing; both have their strengths and weaknesses. and who cares? use what you want. that part, at least, is simple enough.

No, it's not as "simple" as you say. I'm a web developer and if it's true that it's not the same that VST design, one thing i can say is: Time is the most precious thing in the programming process of an app.

I mean, between browsers there are web standards which make everything work on all browsers, common code, common libraries, same fonts, etc.... Is a logic thing, making everything work with standards to make the users and programmers life easier, right?

So, you think that if some browser decides to change everything suddenly and make me loose hours, days, even weeks making a second code ONLY for that browser (and God knows if it will work), it's worthy? only because why, a Browser is a Browser?... No

I don't expect the user to comprehend what a programmer does because it's not an obligation, but if you see that team who makes your VST is struggling with the nonsense of a company wanting to be "Innovative" but the only thing it does is wasting our time and make mistakes over and over, don't push them and help them to do their work.

Synapse Audio has done an impressive work with DUNE 3 and all of their software, and the effort they've put on it to give that infinite picture full of capabilities, amazing sounds, and the best performance and stability between many other plugins, at least for me, it's my go-to for my music and i thanks them for that . That's my opinion and i know many of you think like me, so, instead of complaining, help them and be supportive, the difficulties exist and the only way to solve them is being realistic.

[Jazzguitar]

@nucleox: it couldn't be said any better!!

[Hink]

@nucleox: it couldn't be said any better!!

enie meanie minie mo

[zerocrossing]

If you spent the time that you used complaining about the patch browser on learning how to make your own great sounds, you wouldn’t need a great patch browser.

[accessdune3]

If you spent the time that you used complaining about the patch browser on learning how to make your own great sounds, you wouldn’t need a great patch browser.

Thats such a nonsense. What does knowing how to create patches has to do with patch browser has to do ? I have made over 300 usable sounds, its hard to navigate. Having a simple favourite or tagging or rename in place would be so much easier.

[AnX]

If you spent the time that you used complaining about the patch browser on learning how to make your own great sounds, you wouldn’t need a great patch browser.

Thats such a nonsense. What does knowing how to create patches has to do with patch browser has to do ? I have made over 300 usable sounds, its hard to navigate

it really isn't

[accessdune3]

If you spent the time that you used complaining about the patch browser on learning how to make your own great sounds, you wouldn’t need a great patch browser.

Thats such a nonsense. What does knowing how to create patches has to do with patch browser has to do ? I have made over 300 usable sounds, its hard to navigate

it really isn't

It really is. And in the end its not about the navigation rather then connection between browser and patching skills.

And im not here to discuss that with you and please dont derail my answer. I know you ANX and you are biased to absolutly all Synapse products, basicly ambasador of them, so your opinion is not needed since it will always going to be positive no matter what.

[AnX]

I test, that's it, and Dune is the only synth of theirs I use

if you can't work out how to navigate folders and organise presets, the problem is your end

[accessdune3]

I test, that's it, and Dune is the only synth of theirs I use

if you can't work out how to navigate folders and organise presets, the problem is your end

I can, and indeed it's not the problem of synapse, but mind you, i also expieriencing how some of the other synth developers (uhe ex) dealt with browsing/saving/organizing/navigating. And when some tasks come in i really wish I wouldn't need to use workarounds on Dune 3.

[Super Piano Hater 64]

I don't expect the user to comprehend what a programmer does because it's not an obligation, but if you see that team who makes your VST is struggling with the nonsense of a company wanting to be "Innovative" but the only thing it does is wasting our time and make mistakes over and over, don't push them and help them to do their work.

Disclaimer before I chime in: I don't use DUNE, but I am a programmer. I maintain a piece of software that has to run as native code on multiple architectures.

I believe that universal binaries make things easier, not harder, for developers who support Macs.

Note that some developers do not support Macs at all. That's their prerogative too. In fact, I expected to see a lot more developers abandoning the Mac last year. Synapse has chosen to stick with it. They clearly believe it's worth the effort. I don't think we can change their minds by debating that here. Instead, let's look at some of the actual work involved.

The single worst part of supporting a new architecture is porting assembly code. On modern x64 processors, audio software frequently uses low-level SSE instructions for DSP. Depending on your language and toolchain, you can make that portable by writing it with compiler SIMD intrinsics the first time around, but that's not necessarily an option for code that needs to be deployed to both Mac OS and Windows. Thus, a lot of developers will have written it in assembly, and they just have to rewrite it.

The second-worst part is dealing with subtle differences in the C ABI and memory model. If this one bites you, it can be a lot harder to debug, but you can typically avoid it by writing "modern" C++ (or whatever higher-level language), keeping a tight leash on your locks and atomics, and never doing cute tricks with type punning or pointer arithmetic.

It sounds to me like they have those two problems more or less figured out. They can build DUNE for Apple Silicon. That's great.

Now they have to build it and rebuild it thousands of times. Any time they change something, the plugin has to be rebuilt so that they can try out their changes and (if all's well so far) send it out for testing.

Here's the funny part: If you make separate Intel and M1 builds, you're doing two separate builds of the plugin. If you instead build universal binaries, you're doing one build.

Lemme rephrase that: For the programmer, making separate Intel and M1 builds is potentially twice as much work as making a universal binary.

Thousands of builds... times two.

Imagine.

[zerocrossing]

If you spent the time that you used complaining about the patch browser on learning how to make your own great sounds, you wouldn’t need a great patch browser.

Thats such a nonsense. What does knowing how to create patches has to do with patch browser has to do ? I have made over 300 usable sounds, its hard to navigate. Having a simple favourite or tagging or rename in place would be so much easier.

Your problem is you make more than you can use or need. Just make patches as needed and you’ll never have to worry. Name them things like songname_bass.

[nucleox]

I don't expect the user to comprehend what a programmer does because it's not an obligation, but if you see that team who makes your VST is struggling with the nonsense of a company wanting to be "Innovative" but the only thing it does is wasting our time and make mistakes over and over, don't push them and help them to do their work.

Disclaimer before I chime in: I don't use DUNE, but I am a programmer. I maintain a piece of software that has to run as native code on multiple architectures.

I believe that universal binaries make things easier, not harder, for developers who support Macs.

Note that some developers do not support Macs at all. That's their prerogative too. In fact, I expected to see a lot more developers abandoning the Mac last year. Synapse has chosen to stick with it. They clearly believe it's worth the effort. I don't think we can change their minds by debating that here. Instead, let's look at some of the actual work involved.

The single worst part of supporting a new architecture is porting assembly code. On modern x64 processors, audio software frequently uses low-level SSE instructions for DSP. Depending on your language and toolchain, you can make that portable by writing it with compiler SIMD intrinsics the first time around, but that's not necessarily an option for code that needs to be deployed to both Mac OS and Windows. Thus, a lot of developers will have written it in assembly, and they just have to rewrite it.

The second-worst part is dealing with subtle differences in the C ABI and memory model. If this one bites you, it can be a lot harder to debug, but you can typically avoid it by writing "modern" C++ (or whatever higher-level language), keeping a tight leash on your locks and atomics, and never doing cute tricks with type punning or pointer arithmetic.

It sounds to me like they have those two problems more or less figured out. They can build DUNE for Apple Silicon. That's great.

Now they have to build it and rebuild it thousands of times. Any time they change something, the plugin has to be rebuilt so that they can try out their changes and (if all's well so far) send it out for testing.

Here's the funny part: If you make separate Intel and M1 builds, you're doing two separate builds of the plugin. If you instead build universal binaries, you're doing one build.

Lemme rephrase that: For the programmer, making separate Intel and M1 builds is potentially twice as much work as making a universal binary.

Thousands of builds... times two.

Imagine.

This is exactly what i was talking about, you couldn't say it more technically better.

Exactly! A universal binary takes more time on making things work with each native library and resource compatible between each other, but at the end as you say it is one binary that works on all platforms and the only thing changing is the compiler.

I mean, i wasn't aware of the advanced things about programming on both systems but damn, having to rebuild everything and do it twice, for each change? that's just ridiculous, aside for the fact of forcing a developer to make its code "Portable" because Apple is that dismissive to not make their bridge platform between architectures good enough to at least make the work lighter.

And i know Rosseta is there but i see it more useless than a car without tires, because 80% of the audio software I've seen it's not on the M1, only the big ones who have the budget and the team to do that.