Cherry Audio Forums

Steve,

Really sorry to hear about the time you spent on this related issue. Unfortunately, Build #6 of MIDISPLITCH addressed a bug spotted in review, and the fix broke your setup by the sounds of it. We can only offer our apologies for this.

To the best of our knowledge as of Build #6, MIDISPLITCH is working as intended, and erroneous documentation has been updated to reflect that - thanks for pointing that out.

On the point that MIDISPLITCH is not working as you'd expect, or would like, this is something we'll take on board as a suggestion for a future update.

Thanks, -Rob @ WI

I have removed the details and documentation of an issue.

OK, thanks Steve. Sounds like there's an issue here - possibly a side effect of the fix / regression bug. Sorry about that! Will investigate and update. -Rob @ WI

I have removed the details and documentation of an issue.

Steve, we've since acknowledged that there's a potential issue and we're investigating.

Thanks, -Rob

I have removed the details and documentation of an issue.

Quick update on this. There was indeed a regression bug introduced in Build #6, both in MIDISPLITCH and MIDIPOLY SPLIT.

We've just pushed fixes in Build #7 for both modules. This should hopefully get us back to the behaviour as per updated docs. If so, we can take a breath and have a think about potential improvements.

We also noticed that POLY SPLIT only worked when receiving on CH 1. It should work on all channels now, but it still sends on CH1 to each output.

Again, that's something we can revisit regarding destination / target channel, if we get enough push from users on this.

A bit of background on the thinking behind the "one channel" thing... Despite these issues slipping through QA, there's a method in the madness around "abandoning" the notion of MIDI channels (other than 1) once inside a VM session, given that connections can be handled (and shown) explicitly using dedicated jacks, cables and splitters. We think / hope that makes more sense to a typical Voltage Modular user who may not be that familiar with MIDI. And ultimately, MIDI channels exist to overcome a hardware limitation that doesn't exist in VM. However, if enough people scream "this is madness" then we can re-consider this "method". However...

We have a lot of MIDI-based modules in the pipeline and adding the option to select source and target channels not only complicates things, in some cases it simply doesn't make sense.

And finally, to get back to the original question, it seems there may be a need to have a utility module that can re-assign MIDI messages from one channel to another, unless that already exists. If we make it, we'll make sure it's free for existing WI MIDI-based module owners.

Rob @ WI.

Hi Rob,

I'm a bit surpriced, that my question resulted in such a heated dialogue.

Because finally the answer was "no", I can formulate a feature request now. And I didn't think of a MIDI channel reassignment.

waferly instruments wrote: We have a lot of MIDI-based modules in the pipeline and adding the option to select source and target channels not only complicates things, in some cases it simply doesn't make sense.

It is common for a MIDI device, that user can select a MIDI transmit channel. For receiving data he can select a specific channel or "ALL".

Basically MIDIMOD4 is inserted in a usual MIDI flow as other MIDI devices. If the device has a "MIDI OUT" only, this will send only data created by the device. If device has a "MIDI IN" too, usually there is also a "MIDI THRU", which merges data from the device and it's "MIDI IN".

Back to MIDIMOD4. Because it gets data from any unknown channel, it should transmit these data unchanged at "OUT", better named "THRU". Otherwise the module does a channel reassignment. So on my view it surely makes sence to define, on which channel created CC messages will be sent and merged to input MIDI data stream at output.

Featur request:
- At least it would be helpful, when user could select a channel, that all four sections of the module will send CC mesages on.
- Advanced feature would be an independend channel selection for each of the module sections.

If there is not enough place on module front for more controls, module setup with the context menue could be used.

Additionally I wanna remark, that VM modules are meant to be useful for all users and all purposes. Modules that can only be used together with modules of same manufacturer remind me very much on principle the Ap... company uses for their products. That is not the kind of VM modules I'd like to add to my library.

Roland