They did it! VCV Rack v1 (actually 1.1.0 by now) is finally released. With support for polyphonic cables.
Modules have to explicitly support this, otherwise they stay mono as they were. In the module browser there is a new tag “Polyphonic” that conveniently lists all modules with appropriate support.
Almost 200 of the free modules already support it! Of course most of the stuff made by the VCV guy (including MIDI-CV and CV-MIDI) and fortunately the very good Vult modules.
Audible Instruments (aka Mutable Instruments) stuff is still mono, mono and poly modules can be mixed though.
Some guys are already porting this to Raspberry Pi 4 - will be interesting how it performs! (There was a port of 0.6.1 to pi3, but this was still quite sluggish UI-wise)
The pi4 port isn’t ready for prime time yet, don’t know how he handles the UI.
Here a related thread:
Patching everything without UI is probably something that has to be designed in from the start, like with Orac.
For VCV I think the minimum would be either a touch screen or screen+mouse.
But of course we can always create patches and bind interesting tweaking options to midi controls. This is probably the more interesting and realistic headless usecase. Having custom knobs and buttons for a matching “patch” could be fun!
Not necessarily, but it would need to have had that in mind as a possibility.
My thought is OSC, handled a little more directly than ORAC. There would essentially need to be a command structure in place for wiring parameters, agnostic to any particular interface.
From there, you’d probably launch with a known template. Pre-select your modules and put them on the rack. Build physical control “modules” following PolyMod conventions. And have PolyMod send OSC from the Teensy module into your Pi.
There’s actually no reason, once it’s listening for arbitrary headless patching commands, why a known template should be required. PolyMod assigns an ID to each “module” and detects what’s been added to a given slot, so an OSC command like “/slot x ID” should be more than sufficient.
I can’t imagine wanting to populate an empty case on stage, nor to hot swap modules during a session, so that isn’t the most important feature to me. But it allow for web based interfaces, which would in turn allow an ensemble to patch something collaboratively with separate touchscreens.
It would also allow the community to build a VR patching environment. Which I can’t imagine the devs haven’t been dreaming of.
As you say, it’s a problem they’d need to consider holistically, and they’d probably need third party module developers to play along. But, it could all be added later, and the specifics of what might be leveraging that needn’t have ever been a design consideration.
Orac can be completely driven from OSC… look at my video showing Push2 integration, that is via the direct OSC interface.
(note: don’t confuse this with the Osc Display protocol, that is deliberately simplified for building quick UIs)
however, Orac is not intended to be anything like VCVrack, it focus is aimed at modular at a ‘simpler level’, as some users don’t want the complexity normal modular bring.
its focus/goal was to allow musicians with no pure data experience to combine organelle patches - a desire frequently expressed on the C&G forums in one way or another.
the issue with vcvrack is that they chose to connect the UI directly to the sound engine… so that really means its not that suitable for headless/pi setups (imho)
note, I love vcvrack, its great on its intended platforms - desktop, but really they have little desire in some areas rPI/arm and touch interfaces … which is ok, at some point you have to decide where you want, as a developer, to spend your limited time/effort.
I think we discussed this very briefly when Orac first launched, but it wasn’t a core feature nor the appropriate time to bombard you with niche questions.
Is the direct OSC interface… viewable in some form? I don’t want to say “documented”, though that is the gist of what I’m asking.
I think you said it could be derived from the Push 2 source code in MEC, but that the MEC code on GitHub was hopelessly out of date at the time. Have you had a chance to update that?
Much of what I’m describing as possibilities for VCV Rack would be… at least theoretically possible on Orac. The key difference being that every module in VCV Rack has a physical layout designed already.
Porting their graphics to VR would be relatively simple, compared to dynamically creating them from scratch, building a user level editor to create their own, etc. Which is a silly example, but it does nicely illustrate where the challenges would lie.
Building PolyMod into a physical interface for Orac gets around much of that, because the user can personalize the hell out of their physical modules.
It’s a compelling idea, and a great project for someone to take on later. (PolyMod’s developer mentioned at one point that he might develop generic module PCBs, along the lines of what Livid used to offer with their DIY line. This probably needs to wait for that to materialize)
Anyway… This all probably doesn’t belong in the VCV Rack thread.
its a bit dated, as there are a few messages that have been added that cover new features
as stated in the doc, you should just be able to act as a dumb client to see that main data flow … so you’ll then see a couple of messages ive not documented like ‘resources’
im sure this is where id have pointed you before, unlikely I pointed you at code… if I had id have just pointed you to OSCBroadcaster/OSCReciever which are the ‘ultimate’ reference… and very easy to read for anyone with any C++ experience
Here Andrew’s stance regarding touch screens: “So I will discourage anyone to attempt to use Rack with a touch screen. It will never reach my quality standards so there’s no point in trying to nudge it in that direction.”
Tried it on my Surface Pro, the buttons are quite fiddly for a 13" screen (or you have to scroll a lot). And it is single touch only atm.
Some people seem to have fun with a bigger touch screen though: https://www.youtube.com/watch?time_continue=20&v=GOH5eZLvV8U
Voltage Modular is a little touch friendlier. It also supports multitouch. But you should really know what you want, just buying everything would be $$$$.
yeah, I read that before… hence why i said it will never really get there for touch screens.
personally, I disagree its ‘impossible’ , I just don’t think he has any inclinations in this area, and wanted to stop be ‘bugged’ about it (it had come up quite a few time prior to this)
yeah, voltage modular is the one i never got into, but probably as my interest in that area wained a bit, and frankly it felt like VCVrack will ultimately win in this area - as their open strategy in the beginning was a very clever way to build momentum to get developers. (even some Reaktor developers have moved over)
anyway, I hope voltage modular keep on extending and improving, as you say, it does have some advantages.
but back to original topic VCVRack v1 is a very nice release, not only poly cable, but things like midi learn make it much more useable … loads of other stuff too, that ive not checked out yet
Yeah, must have been quite a bad day for the CherryAudio guys when they were 90% ready with VM and then VCV was released. UHe also seemed to have ditched their modular plans for the foreseeable future. VCV occupies quite some room and is most likely here to stay (even if Andrew would drop the ball at some point - which doesn’t seem likely in the foreseeable future).
That said there are gazillion non-modular synths out there with quite some overlap. So I think CA still have a justification with convenience and workflow enhancements, UHe still has an edge for realism-per-voice-and-cpu etc. Some variety is imho always good.
yeah absolutely… if anything, I’d think its softube modular that lost out the most.
but Ive not too much sympathy, as I think thats mainly due to the way they were pricing their modules.
of course, VCVrack still has to negotiate the road from ‘free’ to paid… and encourage users to pay for the ‘premium’ version… interesting times.
Has anybody found a good way to get sub-semitone resolution cv from the MIDI-CV module?
Currently I use a mixer (which also supports poly cables), put V/Oct out from MIDI-CV on mixer channel 1 and PW out from MIDI-CV on mixer channel 2 (with a amplification factor of -8 for 24 semitones pitch bend range). Works but is a little bit crude. Best option would be if the V/Oct output could be conviced to consider pitchbend in the first place (like the MIDI 8 MPE module from moDllz which is nice but has the disadvantage that it’s not adapted to poly cables yet - so you need several merge modules to merge the mono cables to poly).
You have to make sure to enable MPE mode of the MIDI-CV module. Right click, poly-mode=MPE (from mono), right click again, set polyphony to (e.g.) 16 (from 1).
Then be sure to use a VCO, VCF and VCA that supports poly (e.g. the ones from vcv or the Vult oscillators and filters). In order to get pitch bends you can use the approach with the in between mixer mentioned above.
It is working nicely once you understand how it is supposed to be used. I guess a poly version of the moDllz MPE module isn’t far off, that would remove the necessity of the in-between mixer for adding up note-pitch and pitchbend. And offer the usual CC-74 modulations for timbre etc. (Currently you either have to “polyphonize” the moDllz module with mergers or use the midi-cc module for cc-74)
Edit: Or if possible with the instrument use CC-1 for timbre, that is supported by the MIDI-CV module already.
Thanks for the tips, but those are exactly the things I did
I tried a 4 voice setup, since I use Seaboard Block, and there’s no space or need for more.
But everytime I had some weird voice stealing going on. For example, when I had 3 fingers pressed into the surface, the 4th stole the voice from the 3d. I even thought if my device is faulty, but then it works as advertised everywhere else.
have you set polyphony to > 3 in the midi-cv module?
Didn’t have these note stealing effects on first try yesterday with Linnstrument.
Edit: polyphonizing the moDllz module with mergers doesn’t seem a good idea atm., there clearly seems to be a bug with pitchbend not being kept per voice but distributed globally. So better use midi-cv with cc-1 and the mixer in the meantime.
Edit: Bug seems to be in the moDllz MPE module, not the merger.
Yep, 4 channels both in the module and in the roli dashboard. I think I’m gonna try Softube’s Modular Rise module in VCV, just to see what that gives me.
One hint: four MPE voices are channels 2-5 (channel 1 is for global events).
When setting the MIDI-CV module to polyphony 4 is seems to listen to channels 1-4 though. So to play with four voices best set the polyphony of the MIDI-CV module to >= 5. Worked for me with the Linnstrument when setting the channels to 2-5.
Here a minimalistic MPE example patch (using just the fundamentals modules). It is tailored for +/-24semitones pitchbend range (for other ranges the scaling factor of the mixer has to be changed). Set y-modulation to CC-1: http://fstrixner.de/files/VCV/SimpleMPE.vcv
Thanks a lot! The patch works best if I just leave the number of channels in the module at 16.
Dunno about Linnstrument, but for Seaboard its worth adding slew limiters to the gate and aftertouch signals. I used Bacon Glissinator since it is polyphonic.
