Page 3 of 11

Re: Voltage Modular Feature Requests

Posted: Wed Jan 11, 2023 6:01 am
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

Re: Voltage Modular Feature Requests

Posted: Wed Jan 11, 2023 6:05 am
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

Re: Voltage Modular Feature Requests

Posted: Wed Jan 11, 2023 10:40 am
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.

Re: Voltage Modular Feature Requests

Posted: Wed Jan 11, 2023 4:19 pm
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

Re: Voltage Modular Feature Requests

Posted: Thu Jan 12, 2023 2:30 am
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!

Re: Voltage Modular Feature Requests

Posted: Thu Jan 12, 2023 9:42 pm
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.

Re: Voltage Modular Feature Requests

Posted: Sat Jan 14, 2023 11:49 pm
by GusGranite
Hopefully a Cherry Audio developer will jump in to this thread as well and give some feedback.

Re: Voltage Modular Feature Requests

Posted: Sun Jan 15, 2023 12:20 pm
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

Re: Voltage Modular Feature Requests

Posted: Sun Jan 22, 2023 12:02 am
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!

Re: Voltage Modular Feature Requests

Posted: Sun Jan 22, 2023 12:04 am
by GusGranite
Requests from the Voltage Modular Facebook group added to the list.

Any Cherry Audio developers up for jumping in?