Was up looking for my first hard synth. Found a Virus C 2nd hand going about a good proce atm.
Reviewing on youtube brought me across a recommendation of a Korg Wavestate which sounds sick imo.
Tried looking it up to see if zynthian has one of these engines but cant see any. please straighten this out of I’m in the wrong.
Thought to myself, is there a gui based editor for making new synth engines for the Zynthian? How are synth engines like Aeolus, Dexed, FluidSynth etc made?
Guess I wasnt ready to go down this rabbit hole when I first googled Zynthian a few years ago but here we are.
Probably the nearest thing to the virus or wavestate is either Surge or Helm. They offer a lot of modulation options and have many complex oscilator options.
Ah, that wasn’t your question.
There are some tutorials on how to make lv2 plugins on the internet. I believe this is a good place to start. https://m.youtube.com/watch?v=51eHCA4oCEI
Both of those synths are resource hungry and can struggle to run smoothly on Zynthian. Vitalium is a mega synth with lots of features. It can run well but only if you are careful of how much of its power is utilized (which undermines it’s benefit). Sorcer is based on Faust which itself is particularly CPU hungry.
Both may be excellence synths but they are likely to cause more issues than the problems the could solve!
I’m not convinced we will see the big speed boosts done how for. We are already overclocking RPi in V5. I suspect that the move to 64-bit is likely to show significant improvement and the RPi5 may help a bit so combined we may see a smoother system. Also the separation of code for UI and core may facilitate some optimization and maybe options to enable parts of the system in a more modular way.
This is exactly what I was thinking to, speculating about the strategies to boost the Zynthian system of at least a half order of magnitude, in terms of smoothness, speed and computational power.
ZynthianOS is certainly growing in complexity, but also in clear and orderly functional segmentation, with the various pages increasingly defined in their operational character.
I can foresee that the ensuing V6 hardware - or an intermediate V5 revision - might encompass a combination of 64 bit operation, enhanced CPU clock of RPi5, further overclocking and SSD data access, through the announced HAT interface.
In such a hardware context, it would be very beneficial to subdivide the OS in separate functions, customizable in groups as user-defined Scenes/Templates at system startup, in order to avoid loading all the software applications at once.
This would free up significant computing resources, and save overhead power for peaks of intensive calculation.
I suspect that somewhere between your brain-mind and the keyboard what you meant to say got mangled. Or maybe that’s just how you brits talk. However, I think I got the gist - you’re not so optimistic that we will see the 2 to 3 times performance improvement that’s been claimed for the Pi5 over the Pi4. Time will tell.
True, but based on what I’ve read we’ll be able to overclock the Pi5 as well, and hopefully that will multiply whatever performance improvement we get elsewhere.
Yes! and Multiply again.
I’m hoping for a lot more than ‘a bit’ - but once again, time will tell.
Overall, it looks to me like RISC-V has it’s work cut out for it to match the Pi5 now. The next few years look to be exciting - I do hope we’re all around to see them.
No quite significant. Indeed, almost not noticeable with most engines, except perhaps, Pianoteq.
Anyway, performance is not the main reason to move to 64bits.
The new RPi5 will bring us this performance boost, although we shouldn’t expect a 4x improvement. We should be very happy with something between 1.5x and 2x.
