Voltage Modular Feature Requests

For discussion of the Voltage Modular synthesis ecosystem.
UrbanCyborg
Posts: 588
Joined: Mon Nov 15, 2021 9:23 pm

Re: Voltage Modular Feature Requests

Post by UrbanCyborg »

GusGranite, no, because when you disconnect the cables the behavior you want to visually capture goes away. That's the point; the cables are necessary to supply CVs to get the behavior, i.e., LEDs lit, buttons in a specified state, etc.

Reid
Cyberwerks Heavy Industries -- viewforum.php?f=76
GusGranite
Posts: 71
Joined: Fri May 14, 2021 2:16 am

Re: Voltage Modular Feature Requests

Post by GusGranite »

UrbanCyborg wrote: Wed Jan 11, 2023 6:01 am GusGranite, no, because when you disconnect the cables the behavior you want to visually capture goes away. That's the point; the cables are necessary to supply CVs to get the behavior, i.e., LEDs lit, buttons in a specified state, etc.

Reid
Got it! I am totally going to study your store images now lol :D
User avatar
utdgrant
Posts: 535
Joined: Wed Apr 07, 2021 8:58 am
Location: Scotland
Contact:

Re: Voltage Modular Feature Requests

Post by utdgrant »

ChR_is wrote: Tue Jan 10, 2023 1:49 pm true, unfortunately. but global oversampling wouldn't solve that issue neither. modules need to adapt to the samplerate then. if you oversample a filter 2x, its frequency response is effectively halfed. the module needs to adapt to that. since there is no way in the VM api to get the current samplerate dynamically, ALL existing modules by all developers would need to be adapted to a variable samplerate to make it work consistently.

besides oversampling introduces its own issues. mainly latency, which doesn't work well with the 1 operation per sample that VM does. it sounds negligible, but it starts making sense when you think about e.g. a 1 sample long trigger signal in the context of VM.
I agree with everything you say, above. That's why I'd like to push for a resampling/anti-aliasing filter Java library (code) module which can be pulled in by developers on a (VM) module-by-module basis. I'm more than happy with keeping VM ticking over at 48kHz on a system-wide basis. The main problem is that as soon as one module introduces aliasing, it becomes 'baked in' to the audio which propagates downstream from there and to the final output. There is no way to 'unpick' the undesirable signals once they're present in the 48kHz stream.

However, it doesn't even need to be CA who initiate the creation of an upsampling / filtering / downsampling Java module. I'd be willing to put in some effort to create an open-source module for the developer community. I'll start a post in the VMD forum to expand my thoughts further.
______________________
Dome Music Technologies
User avatar
ChR_is
Posts: 106
Joined: Wed Sep 22, 2021 5:48 pm

Re: Voltage Modular Feature Requests

Post by ChR_is »

utdgrant wrote: Wed Jan 11, 2023 10:40 am
ChR_is wrote: Tue Jan 10, 2023 1:49 pm true, unfortunately. but global oversampling wouldn't solve that issue neither. modules need to adapt to the samplerate then. if you oversample a filter 2x, its frequency response is effectively halfed. the module needs to adapt to that. since there is no way in the VM api to get the current samplerate dynamically, ALL existing modules by all developers would need to be adapted to a variable samplerate to make it work consistently.

besides oversampling introduces its own issues. mainly latency, which doesn't work well with the 1 operation per sample that VM does. it sounds negligible, but it starts making sense when you think about e.g. a 1 sample long trigger signal in the context of VM.
I agree with everything you say, above. That's why I'd like to push for a resampling/anti-aliasing filter Java library (code) module which can be pulled in by developers on a (VM) module-by-module basis. I'm more than happy with keeping VM ticking over at 48kHz on a system-wide basis. The main problem is that as soon as one module introduces aliasing, it becomes 'baked in' to the audio which propagates downstream from there and to the final output. There is no way to 'unpick' the undesirable signals once they're present in the 48kHz stream.

However, it doesn't even need to be CA who initiate the creation of an upsampling / filtering / downsampling Java module. I'd be willing to put in some effort to create an open-source module for the developer community. I'll start a post in the VMD forum to expand my thoughts further.
here's oversampling for VMD -> viewtopic.php?t=2669
GusGranite
Posts: 71
Joined: Fri May 14, 2021 2:16 am

Re: Voltage Modular Feature Requests

Post by GusGranite »

ChR_is wrote: Wed Jan 11, 2023 4:19 pm
utdgrant wrote: Wed Jan 11, 2023 10:40 am
ChR_is wrote: Tue Jan 10, 2023 1:49 pm true, unfortunately. but global oversampling wouldn't solve that issue neither. modules need to adapt to the samplerate then. if you oversample a filter 2x, its frequency response is effectively halfed. the module needs to adapt to that. since there is no way in the VM api to get the current samplerate dynamically, ALL existing modules by all developers would need to be adapted to a variable samplerate to make it work consistently.

besides oversampling introduces its own issues. mainly latency, which doesn't work well with the 1 operation per sample that VM does. it sounds negligible, but it starts making sense when you think about e.g. a 1 sample long trigger signal in the context of VM.
I agree with everything you say, above. That's why I'd like to push for a resampling/anti-aliasing filter Java library (code) module which can be pulled in by developers on a (VM) module-by-module basis. I'm more than happy with keeping VM ticking over at 48kHz on a system-wide basis. The main problem is that as soon as one module introduces aliasing, it becomes 'baked in' to the audio which propagates downstream from there and to the final output. There is no way to 'unpick' the undesirable signals once they're present in the 48kHz stream.

However, it doesn't even need to be CA who initiate the creation of an upsampling / filtering / downsampling Java module. I'd be willing to put in some effort to create an open-source module for the developer community. I'll start a post in the VMD forum to expand my thoughts further.
here's oversampling for VMD -> viewtopic.php?t=2669
Nice one!
dayvyg
Posts: 58
Joined: Sat Jun 04, 2022 8:36 pm
Location: Ontario, Canada

Re: Voltage Modular Feature Requests

Post by dayvyg »

Lots of great suggestions. My number 1 request would be collapsible cabinets. 2 would be an option to see the cpu usage of each module.

d.
GusGranite
Posts: 71
Joined: Fri May 14, 2021 2:16 am

Re: Voltage Modular Feature Requests

Post by GusGranite »

Hopefully a Cherry Audio developer will jump in to this thread as well and give some feedback.
UrbanCyborg
Posts: 588
Joined: Mon Nov 15, 2021 9:23 pm

Re: Voltage Modular Feature Requests

Post by UrbanCyborg »

@GusGranite, look at the picture for my First Baker's Dozen Bundle to see what I'm talking about. Several of the modules in that picture had to be fed CVs to get them to light up the way you see them, particularly the meters on Poly SideChain. Those meters don't even show up, otherwise.

Reid
Cyberwerks Heavy Industries -- viewforum.php?f=76
GusGranite
Posts: 71
Joined: Fri May 14, 2021 2:16 am

Re: Voltage Modular Feature Requests

Post by GusGranite »

UrbanCyborg wrote: Sun Jan 15, 2023 12:20 pm @GusGranite, look at the picture for my First Baker's Dozen Bundle to see what I'm talking about. Several of the modules in that picture had to be fed CVs to get them to light up the way you see them, particularly the meters on Poly SideChain. Those meters don't even show up, otherwise.

Reid
Got it!
GusGranite
Posts: 71
Joined: Fri May 14, 2021 2:16 am

Re: Voltage Modular Feature Requests

Post by GusGranite »

Requests from the Voltage Modular Facebook group added to the list.

Any Cherry Audio developers up for jumping in?
Post Reply

Return to “Voltage Modular”