[HN Gopher] Rack 2 (Virtual Eurorack)
___________________________________________________________________
Rack 2 (Virtual Eurorack)
Author : tosh
Score : 126 points
Date : 2021-12-27 15:05 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fredoliveira wrote:
| VCV Rack is such a wonderful piece of software. And I'm glad that
| eurorack manufacturers are using it as a bit of a testing ground
| too.
|
| Lots of people are priced out of hardware modular synthesis, so
| getting Rack is a solid way to dip ones toes into that world. I'm
| unaffiliated, but highly recommend Rack if you're curious about
| modular.
| abletonlive wrote:
| I used to have >$3000 worth of modular and think VCV rack is
| great. It gets you completely into the modular world. Dipping
| toes is like saying pigments or vital is dipping your toes into
| synthesis. It's just jumping right into the ocean honestly.
|
| Hardware generally slows down my workflow to a crawl. There's
| no beating the convenience of bouncing digital instruments.
| Especially for sound design. If you want a new sound with
| modular hardware and want to reuse your modules, you're getting
| rid of your existing patch. There's nothing more limiting than
| feeling like you can't use your gear because the patch it's
| currently configured for is too good to change. That works for
| some people but not for me.
| disease wrote:
| For a beautiful mix of hardware and software, see the Nord
| Modular G2.
| papandada wrote:
| So am I correct in concluding that you sold a bunch of your
| modular hardware and continue to use mainly software now? If
| so what software do you use besides VCV rack and what if any
| other (non-modular) hardware do you use
| fredoliveira wrote:
| Based on their username, I suspect Ableton Live is one such
| piece of software (it's the main DAW I personally use, and
| absolutely love it).
| abletonlive wrote:
| My setup slowly changes as the years progress but things
| are generally pretty simple. Right now the only hardware I
| have is a RME Babyface Pro FS, an arturia polybrute, an
| ableton push2, and Neumann KH310 monitors and the KH750 DSP
| subwoofer. In the past I've owned the Moog SUB37 CV and an
| endless list of eurorack hardware.
|
| Software most frequently used: All the stuff that comes
| bundled in with Ableton Live Suite (their plugins are
| amazing, don't sleep on it - just because it comes w/ your
| DAW doesn't mean it sucks), Arturia pigments, Vital (also
| free, better than serum in my opinion), u-he Diva.
|
| For compressors I'm really using Ableton's stock compressor
| and glue compressor mostly but reach for DMG TrackComp a
| lot. Fabfilter Saturn2 for saturation.
| papandada wrote:
| Thanks for this. I'm such a noob I'm a bit surprised you
| give special attention to compressors, I'll have to look
| more closely at those.
| abletonlive wrote:
| Compressors are super important for character, groove,
| and general loudness - so that's mostly the reason why
| there's so much focus on compressors. Also since we are
| talking about hardware vs software, compressors are
| generally a hotly debated topic on that front.
|
| I highly recommend this video if you're interested in why
| compression matters so much
| https://www.youtube.com/watch?v=K0XGXz6SHco
| mortenjorck wrote:
| I never understood why someone would go out of their way
| to get a specific compressor until I tried an LA-2A
| emulation. Once I heard that signature "squash" from the
| simulated opto-electrical circuit, it clicked.
| fredoliveira wrote:
| Definitely a great point. I think for a lot of people, the
| beauty in modular is in the letting go of the idea of a
| preset, and creating sound that lives today, but is gone
| tomorrow. For a long time, most of the music I made was very
| loop driven (also very quantized and static) -- modular fixed
| that by rewiring my brain to work differently.
|
| I don't think I'll ever go hardware only. The flexibility of
| software is just too good. But modular in general flexes
| different muscles for me, and I like that a lot.
|
| (great username, btw. Been a Live user since version 1)
| abletonlive wrote:
| Yeah for sure. That's the reason why I got into modular in
| the first place. Different workflow. It's just that the
| workflow ended up not working for me personally, but it
| definitely works for some people.
|
| There's also something about for me about being more
| musical if I have physical knobs to play with that are
| mapped to every parameter available. This is largely an
| unsolved problem in virtual instruments. Nobody has really
| made a digital controller that maps nicely to virtual
| instruments, and I suspect the reason is it's because the
| plugin makers refuse to follow a standard to map out their
| parameters in a consistent way. There's work being done
| around some of this w/ Omnisphere and its ability to take
| advantage of your pre-existing hardware to map to all the
| virtual knobs, but I'd like to have a controller in front
| of me that consistently controls all of my virtual
| instruments in a way that makes sense and it mostly can't
| or doesn't exist.
| spankalee wrote:
| Why don't they take contributions? They couldn't do a CLA?
| myself248 wrote:
| The audio world yearns for a VCV competitor with a genuine
| community rather than a serfdom.
| dmicah wrote:
| There should just be a standard for a software module, like
| VST for plug-in instruments. Then they could re-used across
| platforms, and a DAW like Ableton could theoretically host
| them directly without needing an intermediary VST host app
| like Rack.
| PaulDavisThe1st wrote:
| This is a misunderstanding of the difference between a DAW
| and a host like Rack.
|
| Rack performs single-sample processing. DAWs (all of them)
| use block-structured processing.
|
| For a DAW to host modules that are designed for single-
| sample processing would always require an intermediary. It
| might as well be Rack.
| dmicah wrote:
| I know that each cable in VCV Rack imposes a 1-sample
| delay. However isn't the audio still transmitted to the
| audio interface in blocks? It's not clear why a DAW would
| need an intermediary in this case, other than something
| analogous to the VCV Rack 2 Pro VST instrument host. The
| reason not use Rack is so that it could be an open
| standard with multiple host implementations.
| PaulDavisThe1st wrote:
| > It's not clear why a DAW would need an intermediary in
| this case, other than something analogous to the VCV Rack
| 2 Pro VST instrument host.
|
| Because the modules are written to do single sample
| processing, which creates some design imperatives that
| are quite different from those used by regular audio
| plugin APIs where blocks of samples are passed around.
|
| "But, " you may say, " isn't single sample processing
| just passing around blocks of samples with a size == 1?"
|
| Well, sure, technically that's true, but you don't write
| code the same way if you know that the size is always 1.
|
| Ergo, you're going to need something to execute the
| modules in a single-sample style, not block structured.
| That intermediate will be functionally identical to Rack.
|
| Rack's API is completely open source, and anybody else
| could reimplement it. It would be horrible as a general
| audio plugin API, but it's pretty good for "rack
| modules".
| squeaky-clean wrote:
| I believe the new CLAP plugin format U-He and Bitwig have
| recently released is an attempt at this and a few other
| benefits plugins have been lacking for a while.
| PaulDavisThe1st wrote:
| CLAP (like every other audio/MIDI plugin API) does not
| cover single-sample processing, which one of the core
| design ideas in Rack's module API.
|
| And as an aside, CLAP has almost nothing in it that LV2
| didn't already offer, and nothing that could not have
| been added to LV2 using the extension mechanism, but a
| rather severe case of NIH pushed things in the direction
| that they eventually went. It's quite unfortunate.
| detaro wrote:
| My impression is that they view it as their product they are
| building and want full control. Community is useful for
| building plugins, but not to be given influence.
| 999900000999 wrote:
| 100$ isn't a ton of money, but I'd love to test the VST without
| buying it.
|
| I'll try to checkout the standalone later .
| _fzslm wrote:
| cardinal [0] may be of interest to you
|
| [0] https://github.com/DISTRHO/Cardinal
| bambax wrote:
| Cardinal is absolutely fantastic. It's advertised as a "work
| in progress" but already works really great. You can download
| frequent builds in Github actions / artifacts; they are
| available for almost all platforms.
|
| The limitation is it comes with its own modules (most open
| source modules available for VCV) and you can't load external
| modules. But it's already super powerful. Highly recommended.
| PaulDavisThe1st wrote:
| It is important to understand the reason for the
| limitation(s).
|
| Cardinal is intended to be usable just like a conventional
| plugin, which includes having presets that can be exchanged
| between computers (or even between users).
|
| If Cardinal allowed arbitrary modules to be loaded, there's
| no guarantee that when the preset was used on a different
| computer or by a different user it would work, because
| modules could be missing. One idea for Cardinal is to be
| able to build "synths" with it, and then represent the
| result as a preset that could be used anywhere.
|
| The regular Rack plugin version doesn't have this as an
| explicit goal, and therefore it can allow arbitrary modules
| to be loaded. You can certainly have presets, but there's
| no way to ensure that any context in which you use the
| presets have all the required modules.
| 999900000999 wrote:
| This is why I love HN.
|
| I'll try this tonight
| mxmilkiib wrote:
| A quick note that for chat there is #cardinal on Libera
| icambron wrote:
| Question for music folks (I've played with modular synths but
| only in a superficial, toying-around way): is this skeuomorphic
| paradigm really the best way to do this? With a physical system,
| running wires everywhere might be the only way to do it, but it
| seems like in software you have more options on how you manage to
| connect all your components together, and how those components
| are laid out on the screen. But since this tangle-of-wires design
| is popular, perhaps it really is the way to go?
| siver_john wrote:
| With respect to why the developer of this particular developer
| went the way he did, he specifically wanted to give people the
| feeling of working with a modular synth. So while strictly
| speaking it may be "better" that was not the goal. The
| developer in particular has always been fascinated with the
| tactile experience.
| popctrl wrote:
| I have experience with physical eurorack modular synths, visual
| sound programming tools (VCV rack, Max, audioweaver), and DSP
| programming (Supercollider, Matlab). I think the simulated
| wires paradigm IS the best one...for someone who doesn't want
| to learn at least programming and probably also matrix algebra.
| In my experience, sound code is generally a LOT of ugly
| boilerplate code surrounding a few really brilliant lines of
| code that require years of education to understand. But in a
| code-based version of VCV rack, the brilliant code would all be
| inside some object.
|
| You're essentially dealing with connected one-directional
| graphs of arbitrary complexity. Feedback loops are required for
| the eurorack experience. That's pretty easy to lay out
| visually, but I haven't seen good ways of laying it out in
| code. There's room for innovation here; Someone in the
| programming world has a more intuitive, more informative way of
| visualizing data in a graph that could be adapted into DAW
| paradigms.
| sporklpony wrote:
| You might be curious to check out Faust[0] which is a
| functional programming language specifically designed for
| audio dsp, sort of based on a simulated-wire structure.
|
| [0]: https://faust.grame.fr/
| PaulDavisThe1st wrote:
| Faust really operates at a much lower level than Rack. You
| could write a Rack module with Faust, but you wouldn't
| (probably) do the sorts of things you do in Rack in Faust.
| njharman wrote:
| > do this?
|
| What is "this" for you?
|
| For me it is a cheap intro/evaluation tool for the very
| expensive Eurorack hobby. To meet that goal it must be
| skeuomorphic. I can mess around with VCV + maybe a cheap
| (relatively) midi control to get some physicality. To discover
| my interest is superficial and lasts only a few months. Saving
| me from thousands of dollars of more "toys" that just sit on
| shelf.
| icambron wrote:
| Fair; I get that if we're simulating a physical system and
| just trying to be as faithful as possible, the virtual one
| will look just like the physical one, and inherit its
| limitations.
|
| But I guess by "this" I mean "making the sounds I want to
| make". If I'm interested in composing modular software
| components into a synth without regard to its physical
| analog, a wider range of designs is available for how
| "composition" or even "component" are reified. But the patch-
| cables-between-2d-boxes paradigm still seems dominant in that
| domain too, from my casual browsing of it.
| kall wrote:
| I find working with "modules and wires" interfaces that embrace
| digital more productive/fun but I can see the appeal. Two
| patching UIs that I really like are Audulus and Reaktor.
|
| I like the panel/patching split in reaktor, but it's an extra
| abstraction. They added "front panel patching" after all, so it
| must be more appealing to some people.. Audulus with it's
| parameters+patching on one level but no skeumorphism is at the
| other side of the spectrum.
| icambron wrote:
| Right, I found Audulus 3 much more intuitive when playing
| around (I have the iPad app). It was skeuomorphic in the
| sense that the components were little doodads you connect
| together, but, yeah, the patching and "space" was much
| more...softwareish?
| gfour wrote:
| This isn't just skeuomorphism as found in e.g. a VST plugin
| with a sci-fi UI or a patching language with a UI resembling
| studio-like effect chains. This is a simulator of a real
| implementation of modular patching (Eurorack), for example
| signals mimic real Volt scaling and the dark mode is like
| actually dimming your room lights. So, questions of how to
| "develop" in this mindset can also be directed to users of the
| actual hardware, who do not go through a computer UI.
| squeaky-clean wrote:
| I prefer it for synths that are very modular like these. There
| are other synths with just as deep a modulation capabilities
| and capabilities to route inputs and outputs and create
| feedback loops, etc. But the jumbled mess of cables is easier
| to follow than a big table of dropdowns, or a massive N x N
| matrix, or dynamic labels that appear over controls being
| modulated.
|
| But also part of the whole thing with modular synthesizers is
| you use whatever modules you want. As few as you want, or as
| many as your CPU can handle (or more if you're willing to ditch
| realtime).
|
| So you would need a UI paradigm that can work for 2 modules
| with a couple inputs and outputs each, but also with a massive
| rack of hundreds of modules with up to dozen of inputs and
| outputs each. Do I want my fifth VCO to plug into input 3 of my
| fourth VCA? I'd rather just follow a cable visually.
|
| Some synths do have a great UI that works for them. Razor and
| the original Massive are still among my favorite UI's for
| usability. But they're also more limited in their scope. (Yeah
| Massive is a really complex synth and could be your only synth
| for life, but true modular emulation style synths have an
| infinitely higher ceiling of possibilities).
| udbhavs wrote:
| It's certainly messy because it tries to mimic the hardware
| 1:1, but there are more ergonomic alternatives.
|
| Some examples: Bitwig's Grid (https://www.bitwig.com/the-grid/)
| and Patcher in FL Studio (https://www.image-line.com/fl-studio-
| learning/fl-studio-onli...). Afaik there is no equivalent in
| Ableton which I really miss sometimes (unless you consider
| Max4Live which is on a different level of usability).
| PaulDavisThe1st wrote:
| What do you think that Rack "tries to mimic [ from hardware
| ]" that Bitwig's grid does not? Are you just refering to the
| knobs etc.? If so, that's not in Rack's domain at all: module
| developers control their module's appearance, and there some
| which are extremely skeuomorphic, and some which are not.
| Bitwig's Grid is uniform and consistently non-skeuomorphic,
| but is also (IIUC) not open to 3rd party device/module
| development.
| JodieBenitez wrote:
| mortenjorck wrote:
| In general, the wire tangle is an integral part of any signal-
| routing system, whether physical wires in hardware, a
| replication of those wires in software, or a less skeuomorphic
| box-and-pin model like Reaktor (which itself has a hardware-
| style layer with "cables" called Reaktor Blocks).
|
| The one drawback I find to replicating hardware, as VCV Rack
| does, versus something originating in the digital realm, is
| that more complex modules bring over their hardware-based UI
| compromises.
|
| An example of this is the Plaits module from Mutable
| Instruments, called "Macro Oscillator 2" in VCV Rack. The
| hardware Plaits module is very compact, and uses a series of
| LEDs with little icons next to them to denote which DSP
| algorithm it's running. The only way to know what anything does
| is to look up that icon in the manual and read what each of the
| knobs do in that mode.
|
| In a software-first paradigm, the UI would use a software UI
| pattern rather than a hardware one, most likely a drop-down
| menu instead of a row of icons, and the labels on the knobs
| would change based on the mode (this is actually how a port I'm
| working on of Plaits to the Reason environment is designed).
|
| All that said, many modules in VCV Rack are quite simple and
| would be no different if they originated in software. Things
| like basic oscillators, envelope generators, and filters need
| no manual diving if you understand the fundamentals.
| Applejinx wrote:
| I don't think so. The project that got my love was Bespoke,
| which is node-based but not skeuomorphic :)
|
| Right now I'm polishing a hybrid system, with hardware Eurorack
| coming into Bespoke through multichannel audio.
| papandada wrote:
| Only a partial answer because I never get around to digging
| into it myself, but there is at least one other paradigm out
| there, "live coding", such as supercollider, csound, uh, more
| I'm sure.
| martyvis wrote:
| Sonic Pi and Chuck are two others
| dmicah wrote:
| No, but there were already other software synthesis options
| available for people who don't want a skeuomorphic interface,
| as various levels of complexity - Max/MSP, PureData, Reaktor,
| CSound, SuperCollider, Audulus, KarmaFX, etc.
| tomcam wrote:
| Absolutely not, in my opinion. And I was using those rack
| systems 50 years ago when it was all they had. For a good UI
| try Korg Gadget 2 on iOS.
| tomcam wrote:
| I don't mean to denigrate the VCV team, who do amazing work.
| I love everything but the UI, but I also understand it's the
| UI they wanted. But even as a kid I couldn't wait for patch
| cords to be replaced.
| fredoliveira wrote:
| I guess the design ethos of Rack is really to be a software-
| based Eurorack "simulation", and in that case, being fully
| skeuomorphic makes sense -- you can't have eurorack without the
| rack system or the wires for CV/audio.
|
| That said, in general, what you see in software is a lot
| different. Mentioned elsewhere in this thread is Ableton Live
| (that has been around for many years) and is a DAW with a very
| clear design language that is all about the workflow and quite
| far from any real world device. But that's not to say that
| either approach is right/wrong - they both work.
| PaulDavisThe1st wrote:
| There are essentially no dataflows within Live that model
| what happens in Rack. That's not true in some other DAWs, and
| is certainly not true in various other audio software.
| Consequently, Live's approach to "what you see" is just not
| an appropriate comparison here. It's different, but that's
| because it's really a completely different kind of workflow,
| not just "a different way of doing similar things".
| fartcannon wrote:
| All I can say is wow. Looks great.
| indigochill wrote:
| I'm curious about the pros/cons of Rack vs Reaktor. A Reddit
| comparison says VCV is better for modular by a mile, but not
| exactly why. Is it that it has a better library of modules? Or is
| more focused on emulating hardware modules than Reaktor is?
| PaulDavisThe1st wrote:
| A much bigger library of modules with a lot more funky ideas
| about module function and operation.
| capableweb wrote:
| Would have been better to submit
| https://vcvrack.com/news/2021-11-30-Rack-2-released since it goes
| through the new features. Also, not sure why the full name is not
| in the submission title? (VCV Rack)
| borepop wrote:
| Or just https://vcvrack.com/ ? I don't understand the impulse
| on HN to make everything as technical as possible.
| capableweb wrote:
| VCV Rack has been featured a lot of times on HN
| (https://hn.algolia.com/?q=vcv+rack), and judging by the "2"
| in the submission title, I think OP wanted to highlight the
| new version that was just released, hence appropriate to link
| to the release logs instead.
|
| > I don't understand the impulse on HN to make everything as
| technical as possible.
|
| Well, it is called "Hacker News" and hackers tend to be
| technical, kind of makes sense.
| oarsinsync wrote:
| Having multiple links would be helpful here, so I've upvoted
| yours in the hopes it stays near or at the top.
|
| In a place like this, I'd rather see the source code as the
| headline link, rather than a press release, but the press
| release is still valuable.
| SweetLullaby wrote:
| agree!
| Cyclical wrote:
| Wonderful to see this finally get released. A lot of people
| (myself included) have been awaiting with bated breath for 2 full
| years for VCV Rack 2.
|
| It impresses me to this day that Andrew Belt is the sole
| developer on the project. He's been able to do something
| tremendous in a relatively short amount of time for just one guy.
| PaulDavisThe1st wrote:
| While what Andrew did in _code_ is great, what I think has been
| even more impressive than that is to have created, sustained
| and nurtured a community, an API and an ecosystem that has in
| turn allowed hundreds of other people to construct the modules
| that actually make Rack what it is.
|
| I'm not too jealous of the code accomplishments, but the
| ecosystem is a really strong envy point for me.
| aspenmayer wrote:
| Some context from a third party VCV Rack plugin developer:
|
| > The last straw concerned the policy about taking over inactive
| modules. About making it possible by default for someone to take
| over my very name, Aria Salvatrice, and releasing their own fork
| of my software under my name.
|
| > That's right: if I'm inactive for just one short little month,
| someone else can just go ahead and release software under my
| name, my name as a person, with no process in place for me to
| reclaim it later, even if their releases have low quality
| standards, even if they add ill-conceived features that work
| against my long-term plans.
|
| > It would be easier to continue my work if there existed a
| healthier fork to migrate to, but VCV has been trying to prevent
| forks both through legal and social means, so there's no viable
| fork yet.
|
| > There's MiRack[0][1], a fork of VCV for Mac OS and iPhone. Any
| mention of it within the VCV community is immediately deleted,
| and its author is banned, so it exists completely disconnected
| from the VCV community, despite offering a smaller selection of
| the same modules with mobile support, which is something the
| community really wanted badly. Being only for Apple devices makes
| it impractical for me to use, so moving my development to it
| isn't an option, unfortunately, if it were on PC I might have
| done that.
|
| https://aria.dog/barks/why-i-will-never-create-modules-for-v...
|
| Discussed on HN:
|
| https://news.ycombinator.com/item?id=27032669
|
| [0] https://mirack.app/
|
| [1] https://github.com/miRackModular
| PaulDavisThe1st wrote:
| I cam across Aria's complaints about their experience as a
| developer within the Rack ecosystem, and I was very
| disappointed to read it. It made me reevaluate what I thought
| about Rack and Andrew's handling of the project.
|
| However, somebody then gave me a link to what is apparently one
| of the main threads [0] in which they and Andrew Belt's main
| developer "got into it", and after reading that I was much less
| certain about who was behaving badly here (if anyone).
|
| [0] https://community.vcvrack.com/t/do-open-source-plugins-
| need-...
|
| Regarding the MiRack fork ... I am not certain, but I suspect
| that this author acted in specific ways that upset Andrew. I
| talk regularly to the developer of Cardinal (mentioned below),
| which is another fork of Rack, and thus far, things between
| them and Andrew have remained reasonably cordial.
|
| Certainly as the developer of another open source audio
| project, if someone behaved the way the MiRack developer
| _seems_ to have done [1], I would likely seek to exclude them
| from our community too.
|
| [1] I stress the _seems_ because it really is not entirely
| clear what took place.
| aspenmayer wrote:
| Thanks for that added context. I think it is a tricky
| situation but I guess the rights of the author would extend
| to them requesting that their name be removed from forks that
| they don't agree with, including from the title. However, I
| don't know if the author should be able to force you to
| change the title of a fork that they themselves didn't make,
| whether they currently maintain the software or not. It is
| still accurate to say that it is a fork of a prior state of
| the project, even if it has since been modified. It gets into
| Ship of Theseus territory.
| AriaSalvatrice wrote:
| It's unfortunate that my article, that was only meant to
| reach fellow module developers after my messages were deleted
| from the VCV community, was Streisanded and misinterpreted
| like that.
|
| Most of us who have quit have not quit due to one incident,
| but due to a pattern of behavior over months. The incident
| you are bringing up was just the last straw. And what you are
| linking to is only what remains of the incident, as posts are
| often deleted, and disagreeing with moderation goes against
| VCV's code of conduct. Please do not assume you can read the
| archives of any incident and see an honest account of the
| full chronology.
|
| The last time my article showed up on HN, a few people
| complained that my "product announcement" was too long and
| confused. Had I known it'd be on HN, I would never have
| mentioned what I was up to, as I have nothing to sell. I
| operate in an entirely different way than HN startup culture.
| These are passion projects done on my own time, and passion
| is fickle. Writing about my experiences was in part about
| making my peace with half a year of lost creative drive about
| music hacking. The audience was meant to be the dozen of
| fellow third-party developers who were fed up with coping
| with hostility and impostor syndrome.
| PaulDavisThe1st wrote:
| As I said earlier, I was very disappointed to read of your
| experience as a Rack module developer (not least of the
| reasons: I use your modules often!)
|
| However, this is a bit of a problem:
|
| > Please do not assume you can read the archives of any
| incident and see an honest account of the full chronology.
|
| The fact that Belt's handling of the module developer
| community has gained some notoriety that cannot be
| evaluated by reading "the full chronology" makes it
| extremely hard for those of us not involved in the original
| exchanges to make any confident assessment of what has
| taken place.
|
| At this point, to be honest, the reading around of various
| threads (edited as they may be) related to all this left me
| with this as my only conclusion: your own personal style
| and beliefs and andrew belt's are deeply incompatible and
| it is probably best for everyone that you've chosen other
| pathways (you seemed deeply and personally hurt, and I
| could pretty much guarantee that it would happen again). I
| felt sympathy for both of your positions (at least as far
| as I could read them), and saw them as mostly
| irreconcilable.
|
| I'm open to having my mind changed in the future. Your
| experience has certainly made me wonder if and how often I
| ever acted in a similar way that you feel Belt did, within
| the community of Ardour developers. I can remember only one
| (recent) incident in which someone felt they deserved
| explicit recognition for their part in a process. I hope
| that's the extent of it.
| StyloBill wrote:
| Wow. Thank you for bringing perspective, I wasn't aware of
| Aria's work (which is absolutely incredible) and of what's
| happening behind the scenes of VCV. It's very disappointing as
| the product is amazing and lowers the barrier to entry to the
| eurorack ecosystem.
| klinskyc wrote:
| Saw this, thought it was a new version of the Ruby server, and
| got excited. Synths are cool too though!
| strenholme wrote:
| Since some people don't like the cathedral development style VCV
| rack uses, I point people to a fork of an older version of VCV
| rack with two features VCV rack 2 doesn't have:
|
| * It can run as a VST plugin, so one can use it with their
| favorite digital audio workstation (DAW)
|
| * The code is BSD licensed
|
| Here is that VST plugin fork:
| https://github.com/bsp2/VeeSeeVSTRack#downloads
___________________________________________________________________
(page generated 2021-12-27 23:00 UTC)