More than AUDIO 16?

:wink:

1 Like

2 Likes

when using the MOOG clone, the BUCHLA and the SERGE at the same time, ive more than 64 CV’s … so - please - give me a AUDIO 32 and a AUDIO 64 … - ill pay for it :wink:

2 Likes

No need for paying, maybe some commissioned VCV product photography in front of that 5U…

I now realize that following his suggestion was a bad idea. I should have added support in Rack’s audio driver to allow combining similar audio devices. But since we have AUDIO-16, we might as well keep it, even if this feature is added.

2 Likes

you can have any photo you want, when giving me more inputs!!!
… i have at least 64 CV outs on the MADIface and a second device inside with 64 more ADAT’s - theses goes to 4 ES-3’s.

VCV is really great in its possibilities … only this little bottleneck with the outputs limit. …

1 Like

I did a quick hack, it is easy to create an Audio 32 or Audio 64 instrument:

When using it, CPU usage on my Surface Pro was about 30% with this test patch:

The destination of all the audio data was a TM7 with a Dante card:

4 Likes

very nice - i also would like to be able to do such “quick hacks” :slight_smile:

is this downloadable? :slight_smile:

EDIT. have it - thanks :)))

You should‘t use the original panel. It is created by Grayscale and its license doesn’t allow modified adaptions.

2 Likes

Definitely like the idea of more than Audio 16.

You can’t use multiple audio modules with different devices in Rack, or multiple audio modules with the same device to get to outputs past 16.

And if you aggregate audio devices to get round the multiple devices limitation, you quickly run out of ins/outs. My regular interface is 10 in and 14 out and the ES-8 is 12 in and 16 out making a total of 22 in and 30 out if aggregated.

It’s not that you necessarily need to use them all at the same time, but as there is no way of choosing the ins and outs in an aggregated device, or defining the order they present themselves in, you might want to be using say outs 29/30 even if you are not using 3-14 for example.

One of Rack’s stated aims is to integrate into existing professional workflows, and I think probably most important part of being able to do that is removing any limitations to ins and outs.

The ideal audio module for me would start at say 16 in/outs and then being able to select say 24, 32, 48, 64 channels in the context menu and it would dynamically expand as required (pushing other modules to the right if it needs the space).

1 Like

swoon

You are right, and you might have noticed that I removed the VCV logo, so that there is not the impression that it is endorsed by Andrew or Grayscale. And I wouldn’t publish any plugin or my modified version of VCV Rack with the panel. But I just asked Grayscale if he allows that I provide a download link for testing.

I think this is only a temporary solution anyway. Would be much better if I could just choose the number of channels in a menu of the module and then it would adjust the size accordingly, and generate the new panel graphics by code. Or maybe this would be a good application for the new extension mechanism. There would be a 8 channel base module, and then you could add additional 8 channel extension modules, which would automatically adjust the channel numbers.

4 Likes

I responded to the panel questions by email but just wanted to add that making Audio modules chainable through the new expander module mechanism seems like a good solution that would cover all use cases and avoid maintaining so many different versions of the Audio interface module.

1 Like

I created a feature request on GitHub some weeks ago asking for an expander for the Audio-module, but Andrew declined it.

Expanders aren’t the best solution either. Users shouldn’t think of the right Audio communicating with the left module (or vise versa) which is the point of expanders. They should think that both modules are communicating independently to the audio driver.

1 Like

I‘ve been looking through Rack‘s code for the last two weeks and noticed many good design decisions. I believe you come up with a well-thought-out solution for this demand too when time will come :+1: :slightly_smiling_face:

1 Like

Yes, this would be another good solution, and doesn’t work at the moment, as reported by my bug report. But what happens if the user creates 2 audio modules, configured to the same audio channels? Maybe just adding the signals would be a good idea, or showing a warning.

“You are right, and you might have noticed that I removed the VCV logo …”

Still looks 100% Grayscale, but … none of my bizness. :crazy_face:

1 Like

Given Rack already has the capability to shift a group of modules out of the way, I like the idea of an Audio module that dynamically expands in size to the chosen input/output configuration more than adding separate expanders.

On a related note, it would also be good if we could have multiple audio modules which addressed different devices. Currently that can’t be done without glitching/crashes but I wonder if that is just because Rack isn’t currently coded as to allow/support it, or whether it is a fundamental limitation that technically can’t be done?

There is a fundamental limitation of needing to sync the samplerates of all audio interfaces used in the system.

I don’t think there is such a limitation. You can already use a different engine samplerate than audio interface samplerate.