Is there a current solution for this? if not, seems like an easy module to create (me, who knows nothing of module development), would love to see one!
Perhaps someone could point me in the right direction regarding sending MIDI out of VCV Rack and converting it to DMX in another software, and then out of my computer via USB using something like an Enttec DMX USB Pro box
Lightjams with a MIDI loopback driver would be a good starting point. You could look at the DecaBox Protocol Bridge if you want the conversion to happen in hardware.
Embedding a USB drive to let a module speak directly to an Enttec or equivalent would be possible but I donât see any advantage over the loopback solutions.
If youâre thinking of creating the actual DMX signal in Rack itself, itâs probably not impossible. I think youâd need a USAMO-like audio-to-hardware solution to drive the output, since AFAIK thereâs no 3.5ââ specification that would let you go directly from an audio jack.
I use Rack â Midi â QLC+ â hardware (ENTTEC or DMXKing usb dongle) on Mac. After you spend a decent amount of time configuring, it runs fairly solid.
If you think it would be easy/trivial to code a DMX output widget for Rack, go nuts. I think that would be rather difficult. A lot of hard choices about persistence/precedence, a lot more than relatively simple LIFO/FIFO decisionsâŚthese hard choices are baked into every DMX environment youâve ever used, even a cheap elation or amercanDJ controller.
Hey @zakforrest - guessing youâre coming from modwiggler where hope I didnât lead you completely astray. Iâm sure someone here will set you straight!
I think we settled on a pretty cool solution in modwigglerâŚ
I made posts here, modwiggler, and the touch designer forums all in the same day.
The solution Iâve landed on is:
VCV rack Audio/CV (using black hole) or OSC signals (trowasoft osc module) into touch designer and then send out as dmx in touch designer using Enttec DMX USB Pro. What does everyone think of this idea?
I havenât tried it yet but thatâs my plan.
I just acquired a 256 channel black hole version, so maybe Iâll forget OSC and try direct audio/CV with that. What would be more taxing on the system, 192 CV channels or 192 OSC channels. Or are they both kind of the same?
Out of the box you can use the Audio 16 for 16 audio channels. I think youâd need to roll your own for greater than that. Glad overall that youâre converging on a solution!
192 OSC channels will be much, much, much lighter than 192 CV channels. Each CV channel (Iâm assuming monophonic use here) is an audio channel running at full rate.
Yes/no. Each CV channel is an audio channel running at the interfaces rate. Iâve a setup that uses 54 audio channels @ 4 kHz. Itâs a matter of the interface supporting such a rate.
I donât know enough about OSC to say how that compares for resources. You could still be very well correct that OSC is lighter even if the channels were not running at audio rate.
How DMX channels are updated. You have a LFO red thing going on, and youâve coded a bump button to flash all white. Do the red fixtures go all white or continue their pattern? And if they go all white, what do they do after you release that bump? Back to red at the top of that stack, or pick up wherever in the LFO they were before you hit the bump? Or to blackout?
And then you have the inherent framerate limitations with DMX. Oh, that one red fixture is on channel 191, the packet updated before it got to that channel so that fixture stayed on red while all the others bumped white.
These are all end-user âsolvableâ situations, but the protocol is so stupid that hardware designers had to make difficult/clever choices at the packet level as to how to handle these limitations. Like Blackout always take precedence, for example. Anyway, I assume youâd have to make these choices from scratch if designing any module that spit out DMX.
Wow thanks for pointing that out. If I used some special software thatâs designed to make DMX chase patterns and such, would that fix any potential problems like the one you described with channel 191 not updating like the others
Sure! Underclocking will save you linearly. Interesting setup, by the wayâIâm not sure Iâve ever seen an interface that can go that low! Iâd love to learn more about your application.
Maybe I erred in assuming that OP was reaching for VCV Rack in order to mix DMX and audio? (All sounds are beautifulâheck, Iâve run audio over Midi CC before to get alias and jitterâbut most audio applications are going to want to address frequencies > 2kHzâŚ)
Anyway, assuming weâre in control-only territory and running at ultra-low sample rates, OSC is going to be a lot closer. The main difference is that the CV channels are constant bandwidth whereas OSC is packetized, so (generally) the OSC channels are going to be a lot busier if theyâre all changing and nearly quiet if not. This has advantages and disadvantages. One advantage of CV/constant bandwidth is that if it ever works it should work all the time, whereas with OSC, or MIDI, or something else with packets, you can saturate the channel(s) by surprise.
I mean, youâve been recommended a number of DMX softwares by me and others. Maybe time to start playing with them yourself? And read that wiki page I linked above.
Thereâs nothing specific about âchannel 191ââŚI was just trying to give a concrete example. The general concept to learn is that DMX is a packet-based protocol with no parity checks or other mechanism to see if a packet was received at its destination. And it sends from low to high order. So DMX address 1 generally always gets thru. The greater number of channels you have involved, the greater chance that higher numbered channels get dropped.
Anyway, Iâm out of advice on this topic; again I recommend that you just get hands-on with. it.