Only 4 audio sources no matter the hardware?

[Rayder Rich]

I use Voltage Modular, and purchased quite a few additions already. I also started my hardware modular journey 8 weeks ago and my plan was always to combine the two worlds into a hybrid setup. For this to work well, I want to process audio from my hardware modules with effects in software. I use an 18 channel audio interface, and all of its inputs and outputs are available through ASIO, but in the "Audio Sources" section of Volateg Modular I only have 1L, 1R, 2L and 2R available. In the settings I can only choose 2 stereo pairs to work with.
Can a developer confirm that this is an oversight on my part, or your part, as surely the software should not be limited to only 4 ins and outs while I have 18 of each available to me.

[ColinP]

Hi,

This has been raised before and unfortunately it does appear that VM is linited to just four inputs and eight outputs.

It might be worth emailing Cherry Audio with a direct request as it could have more impact than posting here. This forum is mostly users and third party devs chatting amongst ourselves. Although Cherry Audio folk do pop up now and then.

I think it might be feasible to write a third party module that handled extra I/O but I've not looked into it in any detail as my plate is already full. Given that this keeps popping up some other dev might step forward.

It doesn't seem to be possible to run multiple instances of VM standalone but you might be able to get somewhere by running multiple instances of VM as a plugin inside a DAW. Then you might be able to run more than four channels of audio through VM processing and back to the DAW. But there wouldn't be any communication between the VM instances. Although you might be able to rig some workaround for this.

There's a hell of a lot of "mights" in the above. I'm just trying to provide some feedback. Good luck.

[tgrey]

I think it might be feasible to write a third party module that handled extra I/O but I've not looked into it in any detail as my plate is already full. Given that this keeps popping up some other dev might step forward.

Why not combine the two ideas and just ask Cherry Audio to make a first party module that allows extra IO for users with more advanced setups?

At this point, I think it'd help keep VM competitive with other options that have more flexible IO options. Maybe they'll see it as being in their best interest?

[Steve W]

I think it might be feasible to write a third party module that handled extra I/O but I've not looked into it in any detail as my plate is already full. Given that this keeps popping up some other dev might step forward.

Why not combine the two ideas and just ask Cherry Audio to make a first party module that allows extra IO for users with more advanced setups?

At this point, I think it'd help keep VM competitive with other options that have more flexible IO options. Maybe they'll see it as being in their best interest?

What do you have against third-party developers?

[tgrey]

I think it might be feasible to write a third party module that handled extra I/O but I've not looked into it in any detail as my plate is already full. Given that this keeps popping up some other dev might step forward.

Why not combine the two ideas and just ask Cherry Audio to make a first party module that allows extra IO for users with more advanced setups?

At this point, I think it'd help keep VM competitive with other options that have more flexible IO options. Maybe they'll see it as being in their best interest?

What do you have against third-party developers?

Nothing at all, but since this limits the entire platform for anything but very simple setups, it seemed to me like CA would want to address this.

[Steve W]

Why not combine the two ideas and just ask Cherry Audio to make a first party module that allows extra IO for users with more advanced setups?

At this point, I think it'd help keep VM competitive with other options that have more flexible IO options. Maybe they'll see it as being in their best interest?

What do you have against third-party developers?

Nothing at all, but since this limits the entire platform for anything but very simple setups, it seemed to me like CA would want to address this.

It seems to me that until a third-party developer tries to access and use audio ports available but not shown in VM, we don't know that the entire platform is limited. The way I understand it, CA did what it did with VM including opening it up to third-party developers to extend it. I remember reading a document where this encouragement was stated explicitly.

Very capable and creative third-party developers have done some amazing things. If it turns out that they cannot access additional audio devices/ports, then I would agree their potential use should be built into VMD. Until then, I favor allowing third-party developers to see if they can be accessed and used within VM.

I am not sure that the lack of a first party solution "limits the entire platform for anything but very simple setups."