Patchstorage has lots of VCV patches uploaded. Maybe look there?
Would like to be able to lock my patch and be able to save presets for themā¦
Asked ChatGPT to revise my message. ""Just posted about VCV and its future with ChatGPT! Imagine if VCV had scripting or automation APIsāhuge potential for integration with ChatGPT. APIs like that could really open new creative workflows.
Also, not sure if Apple Silicon is fully supported yet, but Iām hoping for full Mac M3 supportānot just M1. The more Mac optimization, the better.
And hey, how about clever bumper stickers as a feature? Yeah baby!āā
Yeah, Cardinal basically, in low res.
And donāt forget Nanoloop 2.1 now ships integrated into FPGA ARM gameboy
with far more computing power than the āoldā 3dsā.
A Raspberry Pi2 can run Cardinal, even at a minimum, 32Mhz, and 1Gb ram.
It can handle a basic Cardinal song.
The point is releasing a hardware version with all softwares inside would require
perpetual licences. Itās an ownership issue.
Not a ālow power deviceā issue.
Also, the ban of EULAās that says you donāt own nothing for modules
sold commercially.
There must be another way.
A single licence change or future TOS change could shut a server down and bye byeā¦
GPL3+ is not enough?
A light DRM ( unique licence code ) is not enough?
A simple user login and unique code protect the IP holder the same way
a EULA or TOS does, except some 20 million users get screwed overnight and
files a massive class-action refund request, why?
Just why are these needed???
Third!
Some VSTs freeze in Host or display extremely slow (at least on Mac; I donāt know about other machines). I would love Host to work perfectly for any VST because I love VCV so much. I would never have to use another software to use my VSTs.
- A reliable internal timing, better than implemented sinceā¦ the beginning of VCV Rack adventure (2018 or 2019), whatever the presence or not of (well-configured) AUDIO-x module in the rack.
- VCV Library & Store: the ability to have access to ādemo/limitedā modules (same name/SLUG), for non-bought module(s). Many commercial modules canāt be tested prior buy, unfortunately.
- Ability to customize the module displayed by the module browser (RGB LEDs are displayed as white, instead of another color), possible usage of a .PNG.
- Better RGB LEDs, in particular about their blue components: when blue is set to max (and R and G components to 0) this lit as cyan, instead of blue RGB(0x00, 0x00, 0xff). Why?
- Module virtualization, to avoid whole VCV Rack crashes on buggy module(s).
For RGB leds, Rack does a lerp of the full components of NVGcolor colors of the 3 (or however many colors) in the multilight. This simulates the way early multicolor was done when you could only get single-color leds and tunable leds didnāt exist yet.
You can have better control of the color using a single LightWidget and setting its color member.
As for appearance of modules in the module browser, you actually have complete control over how it appears (modulo the caching it does in a session). You can tell youāre in the browser because your ModuleWidget doesnāt have a module. You can choose to draw something thatās wildly different than how it appears in the Rack, not that thatās a good idea (users will complain). If you remember, stoermelder used to show half light, half dark in the browser, but that changed at some point.
Itās good to know that for the online library, the process of capturing the module image is always run with prefer dark panels off, so if you want to show dark panels online, you can do that for the module-less case by ignoring the setting.
3 Likes
@Ohmer; Can you explain what you mean by āreliable internal timingā. Which problem are you referring to?
If youāre using a rack without a well-configured AUDIO-x module, the DSP timings are erratic. Itās visible by blinking lights/LEDs (for example), the blinking looks to be laggy, variable speed, not stable. In worst cases, the module looks to be frozen.
Same āfrozenā behaviors in case the AUDIO-x is present, but badly configured (for example from a downloaded patch), also Rack may crash.
Iāve noticed this on Mac, but not on my Windows machines. Itās a shame because everything else runs so much better. It doesnāt seem consistent either, most plugins work reasonably well, but a few are unusable (Unfiltered Audio Battalion for example). Others run fine, but when modulating controls the GUI doesnāt upate, so you canāt see how settings are changing.
1 Like
You could always forward any light info to your Widget and update lights in an overridden step() method.
The timing in the process function can always be irregular, that is in the nature of things. The OS, ASIO driver or JACK send a block of n samples to process. Then the process method of the whole synth is called n times (resulting in process calls to all modules) as fast as possible. It might be done with the whole block after 20% of n/Samplerate with 80% of the time for one buffer spent doing nothing until the next block arrives. If you set LEDs on and off again in your process() calls, it might be lit up shorter than expected. Couple that with screen updates running at a much slower und uncorrelated rate and you get seemingly unreliable appearance for fast changing LEDs. If your LEDs must get updated that fast, synchonize LEDs with screen updates by setting them in YourWidget::step().
Iād really like to see an official/continuously supported sampler module. A lot of the existing ones crash way too often and/or are no longer being updated.
2 Likes
Youāre mixing up a few things hereā¦
In the first versions of Rack, the engine driving sound producing/processing was Rack itself. That changed somewhere up to the v2 time-frame, canāt remember the date exactly. How it works today (for a long time) is that the audio module is driving the engine and thus the sound producing/processing. What this means is, and people regularly get confused by this, that in order for any signals to get processed in Rack, an audio module needs to be present in the patch, and connected to a functioning audio interface. Before that nothing happens.
With the exception of the GUI processing, which runs in an entirely seperate thread from the audio processing. So if say a LED state gets changed from the audio thread (process()) nothing happens before the audio module is connected, but if itās changed from the GUI thread it will work straight away.
When you download a patch, the first thing you need to do is set the audio module to be connected to your functioning audio interface, before that, as explained above, nothing will happen.
Crashes have nothing to do with any of this at all. It has to do with misbehaving code in modules, always.
2 Likes
What Iāve tried to explain. 
But I agree.
Sometimes (why?) no enough time to change AUDIO settings (or delete AUDIO module), crash may occur prior to do this. I say sometimes. But a ādisabledā AUDIO - if audio interface is different - will be a better solution - like MIDI-based modules, if you controller is turned off, the MIDIāCV for example is automatically set to (no device).
Due to non module virtualisation (perhaps itās very difficult to implement, I presume). As comparison, a DAW like REAPER does it, but sinceā¦ version 5!
I know this (thanks anyway)
Okay, no polemic itās not my goal, just have reported mine impressions, VCV Rack is - and remains - a fantastic software, either for musicians and for developers! And obviously VCV Rack 2 is largely more stable than v1.
Hello there!
Iāve forgot a possible interesting feature would be implemented. Like expander modules (but must be alongside - left or right - another module), the idea is expander concept (like existing) but by using a specific (flat) cable, or āoptical fiberā, like a digital bus, in order to place the expander anywhere youāll want in the rack (instead of along other module).
I donāt know if this concept is existing, or not, in real Eurorack, however.
This is how expander modules work in real Eurorack, you connect them together with cables on the back of the module, usually ribbon cables
For what itās worth, you can make expanders that you can move around after connecting to the main module. For example, pachdeās CHEM modules support this (you connect the modules as if they were normal expanders, and then you can move them anywhere).
You just need to do it manually instead of relying entirely on the built-in expander system. (You could even do your cables idea, itād just take some effort in setting up the UI side of it)
1 Like
Interestingā¦ yep youāre right by meaning āusually ribbon cablesā, it was the idea. I have evoked optical fiber (like SPDIF) used for ADAT technology in studios, and so onā¦
Thank you very much (in particular for tip youāve mentioned about pachdeās CHEM module).
Native implementation in VCV Rack (perhaps v3) will be cool, IMHO.
I have been toying with the idea of creating expander modules that ācommunicateā with their parent(s) via āribbonā cables.
I assume I could somehow piggyback on the existing cable mechanism. I would create specialized āoutputā ports for base modules and āinputā ports for expanders. Expanders could also have an āoutputā port to support chaining where order of connection is important. The ports would probably be rectangular, and the cables would require custom code to visually differentiate them - probably a bit wider than standard polyphonic cables, and with stripes to look sort of ribbony. The point for these special ports and cables is to allow remote connections to expanders, both vertically and horizontally.
I would also have a context menu option (perhaps global) to hide or show the special ports and cables. So show the ports/cables for setup (like connecting ribbon cables in hardware), and then hide during typical operation.
I would probably allow stacking on āoutputā ports so a single module can connect to multiple expanders. I think the expander āinputā ports should not allow stacking, which might be problematic if I build upon existing port and cable architecture. There probably ought to be context menu submenus that show connected parent and children for each module, so you can trace connections when the ports/cables are hidden.
Module code can ātraceā these ribbon cables to establish connections, and communicate via expander messages or direct memory access, just like current expander communication.
I imagine existing API events can be used to detect connect / disconnect actions so that connection tracing only happens as needed - a lot of details to be worked out.
I like to dream about this, but realistically I probably will never attempt to implement it.
Needless to say, it would be a lot nicer if something like this were built into the native VCV architecture.
2 Likes