Cherry Audio Forums

Koshdukai wrote: ↑Sun May 24, 2020 11:49 am To sum up (IMHO):

• "normalled modules": GOOD!
• Buses: GOOD!
• "normalized signals to IO Panel": BAD!

I'm not really referring to this quote specifically, but it seemed unnecessary to quote the whole post.

Also, whilst it may look otherwise, I do not want to 'argue' with you - and hopefully I am NOT arguing with you - I just thought it was an interesting point of hypothetical debate.

That said, despite your extensive explanations, I have to perhaps conclude that I just probably don't fully understand.

I honestly thought that you had mistakenly believed the original modules had midi, so the VM ones should have. The rationale made more sense then. i.e. why remove a potentially useful feature from an emulation. Now it is clear that you know otherwise the debate is seemingly 'why not add a potentially useful feature to the simulation. Certainly not groundless, but there are of course many potential mods one 'could' make in 'virtual' that were nor present on the original. I'd quite like a 'scatter' button (of course I don't expect to get one, but I'd prefer it over a midi in)

Everything you want to do can be done relatively easily. You can even get rid of all "mess" by hiding cables (... though isn't the 'spaghetti' part of the whole virtual modular for some?) Yes, CA could add midi. In fact they could probably add midi directly to many modules, make all parameters CC assignable, and this might be even better for some people, but is this "voltage modular" or "voltage midi patchbay". Educational? I cant see how the use of virtual CV is less educational than plugging in a virtual midi cable (if I 'was' arguing, I would argue the CV approach more educational, but I am not. So I wont) Different sized midi ports. I have different sized midi ports on my equipment. Where is the line drawn. Perhaps virtual USB-C midi 2.0 ports? I exaggerate of course. And I obviously have to concede that the busses feature (which - to be clear - I also like) is still another step away from the simulation of real modular, though doesn't this also assist with the problems that you appear to be highlighting? It should at least reduce the 'mess' a little in the example you provided.

I suppose what caught my attention about your observations was they seemed to suggest the implementation of these modules was flawed without the omissions you note. Perhaps you are not really saying that - as I do not wish to put words into your keyboard - and if you are just listing some 'feature requests' then my points are moot.

In the end, if CA implement any of your ideas I am not going to complain as, in reality, they would not be detrimental to VM in my opinion. On the other hand though, they would not be areas I would ask the developers to focus on as I just cant see the gain (I can see the volume, and the limiter, but not the gain...... sorry couldn't resist).

I would be genuinely interested to hear others opinions though. Not for a who is wrong or who is right, but to perhaps understand a different perspective or usage scenario that favours your proposals.

Until then lets agree that we are very much looking forward to what the future holds for VM 2.0 and beyond.

Well, I really hope CA is reading this exchange of ideas.

On my part, this is how I see it:

CA did a terrific job with the virtualization of CV and was quick to come up with a more elegant support of polyphonic setups through the implementation of PolyCV/Audio, making poly patching as natural as traditional CV/Audio patching without sacrificing the poly aspect nor turning it into a messier experience than what's already the norm with hardware modular.

CA was also smart to include virtual MIDI right from the start, as yet another connection type also extensively used by many when the situation makes it the best choice, providing multi data-types on 1 wire, not losing (if we ignore the loss of value resolution) any flexibility due to the MIDI<->(Poly)CV modules, dealing with Clock, CC, etc.

Same for VST hosting, making a seamless experience between VST parameters and CV, etc.

All this is clear, flexible and smartly designed and educational, meaning, I can use Voltage Modular to teach many things directly applicable to hardware without needing any "ignore that..." and "imagine that..."

CA was again smart to support complete synth modules (Instruments) with normalled connections, bringing into the virtual modular environment something that's also seen in hardware.

CA thought that Buses was a sensible and logic way to hide visible connections between IO points, almost like using the "Source->Destination Matrix" way well known by many already, like the notion of a Bus is to many as well. Having access to such a list of these connections, being able to interfere, change, remove these is as flexible as any of the existing options, providing yet another way to do the same thing and letting the user choose which is the preferred one.


Now the issue is that, the "normalized signals to IO Panel" was unnecessary, but CA chose to spend some design and development time implementing it.
So, if there was a focus on a truly unnecessary feature, then at least make it right.

Just like polyphonic support wasn't done right the first time but perfectly when taken seriously, I think this is yet another example of something not quite thought through. I'm not asking CA to focus on this because CA did it already, so if the option was to focus on it, then focus again until it's done right

If CA really wants to make the UX of adding an Instrument (a complete synth module) to the rack, then implement *visible* self-connecting cables.
If the issue is the visibility of the cables, then use Buses, if that's the user choice (please add a toggle for that).

I'm suggesting MIDI because that'll be the cleanest way to get PolyPitch+PolyGate+PolyVelocity+PitchBend+ModWheel+etc through 1 wire into a complete synth module. But if adding MIDI is such a shocking option to add to an instrument aka complete synth module, then by no means, add all the (Poly)connections needed, but in a way the user can see/inspect and change them, like all the other connections happening in the rack between modules.

That's all I'm asking/suggesting, since there was already some time spent on this unrequested(?) feature, please take advantage of what's already available in VM, which is a lot and very well designed and implemented, IMHO... except this new "normalized signals to IO Panel" idea

...and yes, I'm always looking forward to VM improvements, because, for a while, I almost forgot how much there is to improve, when speaking about container modules (enclosing modules inside, only exposing needed IO+Controls) and extending global (and/or per Cabinet/Container) "Perform" controls, etc...

HI,

I guess you have to ask what emulate means. We're trying to create software versions of vintage synths in this case, and those analog synths did not have MIDI inputs. We could add all sorts of digital goodies to the module, but then would it still be an emulation?

Besides, this is modular synthesis. Most operations take more than one module.

As for the normalled I/O, you can just pretend it isn't there, and hook up cables like you normally would if you want to use it for educational purposes.

Thanks for your feedback!

Greg

cherryaudio Greg wrote: ↑Mon May 25, 2020 3:56 pm As for the normalled I/O, you can just pretend it isn't there

Ok, I'll try to pretend that it's not there.

cherryaudio Greg wrote: ↑Mon May 25, 2020 3:56 pm I guess you have to ask what emulate means. We're trying to create software versions of vintage synths in this case, and those analog synths did not have MIDI inputs. We could add all sorts of digital goodies to the module, but then would it still be an emulation?

It's just a comment from the peanut gallery, but if you were to ask say, Behringer, I'm pretty sure they'd say an added MIDI port doesn't 'unmake' an emulation

And frankly, for the 'Instrument' modules, it *does* seem to make some sense.

But they sound great regardless!

Cheers,
--
Terry McG

terrymcg wrote: ↑Tue May 26, 2020 3:09 am [...] an added MIDI port doesn't 'unmake' an emulation

And frankly, for the 'Instrument' modules, it *does* seem to make some sense. [...]

Thank you. My feelings exactly, more so if there was an intention of making the UX easier... But I'm now totally convinced (from Greg's answers) that "they don't get it" (at least for now).

How can this



be as clean and flexible as this




when the only alternative is this



so I give up

Hi,

Thanks for the suggestion, I'll pass it along!

Greg