[LAU] 1625 [music]

[Dan Ballance]

Thanks for sharing those observations about VCV Rack and the internal
software design in particular.

On Mon, 3 Dec 2018, 13:56 Paul Davis, <paul at linuxaudiosystems.com> wrote:

>
>
> On Mon, Dec 3, 2018 at 7:42 AM Dave Phillips <dlphillips at woh.rr.com>
> wrote:
> [ ... ]
>
> Following on from Louigi's question, I want to say on this mailing list a
> couple of things about VCV Rack that i've said often on IRC but not
> elsewhere. Really just two.
>
> 1) I want to give HUGE thanks and congratulations for Andrew Belt and what
> he has done with VCV Rack. Not so much the program itself, but the
> ecosystem he either deliberately or accidentally created around it. Some of
> you (*cough* Dave *cough*) might remember that before I wrote Ardour and
> JACK, my first foray into Linux audio was something called Quasimodo.
> Powered by a reimplementation of CSound, the GUI was a lot like VCV Rack
> (and other similar software). Quasimodo never succeeded, for a variety of
> reasons, and it is so good to see a GPL'ed modular synth now finally really
> finding and creating a community and success. The visual appeal, ease of
> use, and relatively simple module API of VCV Rack have all been critical in
> its success, and Andrew deserves many kudos for this. It really is amazing
> to see the set of available modules (and their quality) and the dual
> business model (no-cost vs. paid) for modules. I'm actually jealous.
>
> 2) All that being said, as a programmer, the internals of VCV Rack's
> engine are deeply disturbing. It is really amazing that VCV Rack works as
> well as it does. It isn't properly coupled to the audio hardware at all (it
> uses a timer to drive the graph), and  it can't be trivially modified.
> Thankfully, someone has done the modification for the VST version of
> VCVRack (because in a plugin, you have no choice), and so perhaps the
> redesign might make it back into the mainline code. Given the lovely to use
> GUI and the fantastic ecosystem, it's a little sad to see the internal code
> suggest almost no understanding of how to write a realtime audio
> application.  Maybe Andrew had his reasons for the internal design - I
> don't know. But it certainly makes it much more likely to have audio
> glitches and to be incapable of operating at the lowest latencies. It works
> well enough for me, however (and is a huge risk because I could spend hours
> playing with it).
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20181204/f8eae5d9/attachment.html>