Rack: MIDI interface revamp

[AndrewBelt]

Here are my notes for four N modules that will replace the MIDI Interface module. Suggestions? (* is finished, - is unfinished)

* MIDI-to-CV
    * 1V/oct, gate, velocity, pitchwheel, mod, volume, aftertouch outputs
    * MIDI clock output, start/stop gate, song reset outputs
    * LED for each output
    * Be able to use the two interfaces on the same port, useful for MIDI channels
- Quad MIDI-to-CV
    - polyphonic voice asignment modes (rotate, reset, reasign)
    - 4x 1V/oct, 4x gate, 4x velocity outputs
    - pitchwheel, mod, volume outputs
    - LED for each gate
* MIDI CC-to-CV
    * grid of 16 CC voltage outputs
    * select source CC channel for each port by clicking the dropdown on each one
    * LEDs for each output
- CV-to-MIDI
    - 1V/oct, gate, velocity, pitchwheel, mod inputs
    - MIDI clock, start/stop gate, song reset inputs
    - LED for each input
* MIDI-note-to-trigger
    * 16 notes specified with TextFields, or a range of chromatic notes
    * 1ms triggers with digital.hpp's PulseGenerator
* MIDI-clock-to-gate/trigger
    - delay trigger

[AndrewBelt]

Internally, I'll switch to RtMidi because it seems to be more stable and easier to compile.

[danballance]

Sounds great.

I'm not getting any midi devices detected currently, although I've not investigated in any depth. I might open a ticket if I can get some clarity on what the issue looks like. I have some code that's using the python bindings to RtMidi and it's working well for me on Ubuntu Linux 16.04.

[synthi]

Would be possible to add a MIDI Polyphonic module or a polyphonic module built in the Quad? ideally with some voice asignment modes (rotate, reset, reasign,) ad evena paraphonic mode (Polyphonic CV outs but a common gate)

[AndrewBelt]

Quad will be polyphonic. Good suggestion on assignment mode. Can't paraphonic be done by just copying gate 1 for example?

[synthi]

I think you can´t just copy gate 1 when in rotate or reasign mode. Could be useful a "common gate" output in a separate socket and active in all modes so you can fire monophonic events (ie reset an LFO common for al voices,...)within a polyphonic patch.

[TronicLabs]

MIDI Clock, Start, Stop

[Patchbungles]

For the Quad MIDI.. a random assign mode would be cool, a unison mode with detune via small random variance to 1V/Oct. outputs too.
CC to Voltage.. remember there are 127 CC# per MIDI channel, and perhaps add a RPN/NRPN assign mode (where CCs 6 and 38 are used) to give 14-bit resolution (many controllers send these nowadays).

As Troniclabs says.. MIDI clock. With several selectable divided clock outputs.

.. and thanks for this great software! :)

[bontric]

For those who can't wait for midi CC:
I've implemented MIDI CC and velocity. It's not a very pretty solution, but it works for me and might be usable for others.

https://github.com/bontric/Rack-MIDICC-Fork

[nay-seven]

Any chance for a Mac compiled one ? not sure to install X-code only for this...

[bontric]

I don't own a mac but if someone provides me the compiled version I'll add it to the repo. (We should probably not discuss this here, I've opened an issue in my fork )

[synthi]

Compiled windows version also please!!!!

[AndrewBelt]

Feature request: support for 14-bit MIDI CC values? Someone brought that up on the Facebook. Sadly I don't (think I) have a controller that supports this, so I can't test.

[bontric]

Shouldn't be a problem, but I also don't have a compatible controller. I'll just follow the specs and test manually with supercollider.

So:

• Add Mode selector to Midi CC-To-CV (can't support both at the same time since, as far as I understand, it's based on two separate CC messages to control one value)

It shouldn't be a huge deal to implement, but I don't know when I find the time. I'll focus on the basics first. (On a side note: I'm not an electrical engineer, but from my own experience building midi-controllers, common potentiometers are not precise enough to get a 14bit resolution. I guess that's why 14 bit CC is rather uncommon )

[bontric]

@AndrewBelt Just fyi: I'll start working on Quad MIDI-to-CV next, or do you have any other preferences?

[AndrewBelt]

I think that's it, right? I honestly can't think of any other MIDI related modules we need (although someone will come up with sonething as soon as it's released.)

Feel free to get creative with voice assignment modes.

[bontric]

CV-To-Midi is also missing, I'll have to implement another wrapper for that (out is way simpler then midiIn though)

I want to add a clock module which sends midi clock out but also sends CV triggers (This is easier than having a direct CV-To-Midi Clock, since that would require learning tempo from CV triggers etc. which I don't think really adds to the overall experience ). Also then there is no need for 3rd party clocks

Oh and I just realized my trigger module works a bit different from the one proposed here. Rather than sending a trigger it works with the gate. So holding down a key will leave the gate open. That would obviously be only a small adjustment tough.

For the Quad midi I have a question:
Should we have mod/volume on the Quad midi as well? I mean, the midi CC module can also be used to get mod/volume.
I also want to add polyphonic aftertouch for each output (MIDI-to-CV currently only works with channel aftertouch and I don't know whether controllers implement both. So I might want to add note-aftertouch to the normal MIDI-to-CV as well)

I was thinking OSC might be a nice addition to the modules as well, but It's on you whether you want that to be part of core.

And of course I'd like to work on some proper visuals for the midi modules..

Ahh.. so much to do, so little time :)

[AndrewBelt]

Ah yes, I missed that. There are some corner cases like whether off-pitch CV should send a pitch wheel and how much, if we even need that feature. And rate limiting because someone is going to try plugging in a 20kHz square wave into the gate input.

I think using gates is probably fine on trigger-to-CV. Perhaps a right click context menu just like SEQ3?

Using MIDI-to-CV with the quad MIDI-to-CV is a good point. I hadn't thought of that. If using the same device twice simultaneously always works with rtmidi or your MidiIn abstraction, then lets do that.
I'm in favor of aftertouch on quad MIDI.

Let's think about OSC later, but good idea.

Grayscale might be available to design the Core modules at some point, but only after they're stable because I don't want to make him redesign it 10 times. I want flexibility of functionality over well thought out design right now.

[bontric]

And rate limiting because someone is going to try plugging in a 20kHz square wave into the gate input.

:yum: made me lough. Yeah, I'll make sure to add some protection

Using MIDI-to-CV with the quad MIDI-to-CV is a good point. I hasn't thought of that. If using the same device twice simultaneously always works with rtmidi or your MidiIn abstraction, then lets do that.
I'm in favor of aftertouch on quad MIDI.

With the wrapper it should definitely work now without restrictions.
Well, there is one. On Windows using Rack and another DAW could cause problems because the windows API only allows to open a midi device once.(So by default you can't use a midi device with, let's say Ableton and Rack at the time)
However, some device drivers implement support for this and Windows 10 adds a new API (which is not supported by rtMidi yet, but should come soon) . So this is Windows+device specific. Just wanted to note that because someone might open an issue. (I can also write a comprehensive Guide/FAQ for the midi modules at some point)

Grayscale might be available to design the Core modules at some point, but only after they're stable because I don't want to make him redesign it 10 times. I want flexibility over well thought out design right now.

Okay, that's sweet. I'll keep focusing on the features then and try to keep the design clean. I want to change the backgrounds of TextFields and Choice buttons though.. The gray background on white makes them look like the design was stolen from Windows 98..

[AndrewBelt]

You laugh, but I'll get 30 emails about it, haha. Nasty input signals have almost run a particular Eurorack manufacturer out of business due to overlooking that source of bugs, and he vowed to only work on software plugins from then on. Interesting story, but I'll leave it at that.

I should change at least the color scheme to be different from Blender. That would solve the problem.

[bontric]

You laugh, but I'll get 30 emails about it, haha. Nasty input signals have almost run a particular Eurorack manufacturer out of business due to overlooking that source of bugs, and he vowed to only work on software plugins from then on. Interesting story, but I'll leave it at that.

I can only imagine. Seems like people don't really understand that Rack is still an early version. Well ov course everyone is excited about it, but must be really annoying to get all the "why is X not working" mails

I should change at least the color scheme to be different from Blender. That would solve the problem.

Oh I meant only for the midi modules, for the Rack menu it doesn't look too bad.

[bontric]

@AndrewBelt I saw someone on Facebook asking for start/stop gate on the midi clock. It's just a few lines to add this if you want. I left it out because I thought it is kind of redundant (Pulse from the midi Clock module is only sent if the clock received a prior "start" and ends with "stop".), but maybe it also opens up some cool stuff I didn't think about!

[synthi]

@bontric would be great if you could add a common gate, and maybe also a common aftertouch output to the Polyphonic MIDI module, so we can mke paraphonic patches, or controlling monophonic filter or effects in series with the polyphonic "subpatch"

[bontric]

Why not use a QuadMidi to CV parallel to a Midi to CV on the same interface?
I'm always open to adding something and it's usually not a big deal to do, but I'd also like to keep the modules as simple as possible.

[jonheal]

Andrew, I am tempted to buy you a Behringer BCR-2000 so you can test accomodating controllers with 14-bit resolution nrpn encoders. 128 steps just doesn't cut it for smooth filter tweaking, etc.

[AndrewBelt]

I have one but it's in storage at my folks' many miles away. But I'd gladly borrow one to add this feature to the MIDI interfaces.

[bontric]

Adding support for 14 bit controllers is not a huge deal. However, it
requires different handling so the midi to CV interface would require a
different model to allow 14bit midi.

I'll add it once I find the time but I'd suggest we implement smoother midi
transitions first. Some controllers will skip midi messages if a controller
value changes quickly. So turning a knob fast will lead to "jumps" in the
value. Therefore there should be a smoother transition if a knob is turned
quickly to avoid these jumps.

On Oct 29, 2017 12:42 AM, "Andrew Belt" [e-mail] wrote:

I have one but it's in storage at my folks' many miles away. But I'd
gladly borrow one to add this feature to the MIDI interfaces.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/81#issuecomment-340224614, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGPSa_e0OIVlxi2oknNBB9KRoH1ABwOks5sw63QgaJpZM4PYFj1
.

[AndrewBelt]

Yes, exponential smoothing with lambda = 30 to 120Hz would magically make 7-bit controller sound a lot better.

[bontric]

I'll take a look at it. Should be pretty straight forward so we might have
it before the next release.

On Oct 29, 2017 12:58 AM, "Andrew Belt" [e-mail] wrote:

Yes, exponential smoothing with lambda = 30-120Hz would magically make
7-bit controller sound a lot better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/81#issuecomment-340225304, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGPSW-TbMSjPP1hGN5dnhqf5uVWkP6eks5sw7GQgaJpZM4PYFj1
.

[jonheal]

The smoothing at lower frequencies sounds like an awesome solution. And honestly, having to rotate an encoder 59 times to move through all of the possible values does not sound like an optimal user experience, either.

I think the smoothing idea sounds like a great compromise.

Thanks for the super speedy responses. I only learned about VCV Rack yesterday and already I am lamenting the dollars spent on Reason, Rack Extensions and more recently, Reaktor. This VCV Rack is exactly what I have been looking for all these years.

is it possible to make a donation to the project?

[AndrewBelt]

I'm not sure what you mean by "having to rotate an encoder 59 times to move through all of the possible values".

Save your money for a month and buy the commercial plugins when they come out. 😄

[jonheal]

I meant that if my encoder is set to 14-bit, and if the resolution is set to high, then I have to rotate it gobs of times to move through all of the 16000+ possible values. If it's set it to a lower resolution, then you start losing the benefits of 14-bit. All-in-all, it sounds like a 7-bit encoder that gets smoothed at the lower values is the best compromise. That's all I was saying. :-)

[bontric]

Well to achieve a high resolutions in a midi controller you need more steps
since the resolution is restricted by the resolution of encoders. Having a
14 bit resolution means you have to turn your knob multiple times to get to
the highest value. (At least from my understanding)

On Oct 29, 2017 1:41 AM, "Andrew Belt" [e-mail] wrote:

I'm not sure what you mean by "having to rotate an encoder 59 times to
move through all of the possible values".

Save your money for a month and buy the commercial plugins when they come
out. 😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/81#issuecomment-340227026, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGPSeH4HSqEk9kiaOs8xeZ97tQJcDsIks5sw7ucgaJpZM4PYFj1
.

[bontric]

@AndrewBelt So, I spent a couple of hours playing around with CC smoothing. While relatively simple in theory, there are some things to take into account. Here are my results:

1) I tried 3 different transition curves: Linear, exponential and smoothstep. From those I found smoothstep and linear gave the best results, while exponential would still lead to noticeable jumps.

2) The transition phase is a difficult parameter. Your suggest 30-120Hz is way to low to notice any change. For me the best trade off seems to be around 1500HZ (With engine running at 48K, So 1/32 second). The delay is barely noticeable while the resulting smoothed transition makes a very noticeable difference. (I used a VCF frequency and a VCO frequency for reference. Especially controlling a filter with this setting is an incredible difference as compared to no smoothing).

3) There are also more sophisticated approaches which could improve the experience further but also might be a bit confusing. For example: If a Knob is turned slower we could increase the transition phase which leads to an even smoother experience but can also make the knob seem less responsive.

I don't really feel like being in the position to decide whether we should have detailed settings or an experimentally derived ideal value for this. Maybe start off with a default setting an wait for user feedback? What do you think Andrew?

[jonheal]

Thanks for looking into this, Ben, Sounds very encouraging from what you have reported, so far. I think a change like this will make the playability (with a hardware controller) of software like this such a richer and more authentic experience. And you guys are the only ones who are doing this as far as I know. No one else seems to give a rip about 7-bit knob jaggies. THANKS A MILLION for your efforts. 🥇🥇🥇🥇🥇

[bontric]

Thanks for your appreciation man :) I think I found a good solution now which adjusts the transition phase according to the turning speed. The transition is really smooth for me now (with an encoder and a normal potty)

If you are able to compile Rack from sources you can use my branch and test the new feature, See #309 (I'd love some feedback :wink:)

And you guys are the only ones who are doing this as far as I know. No one else seems to give a rip about 7-bit knob jaggies. THANKS A MILLION for your efforts. :1st_place_medal::1st_place_medal::1st_place_medal::1st_place_medal::1st_place_medal:

Seems really strange to me this is not standard.. :octopus:

[jonheal]

Let me try to figure out how to do that …

--
Jon Heal
Have a nice day!

From: Ben
Sent: Sunday, October 29, 2017 2:01 PM
To: VCVRack/Rack
Cc: jonheal; Comment
Subject: Re: [VCVRack/Rack] MIDI interface revamp (#81)

Thanks for your appreciation man :) I think I found a good solution now which adjusts the transition phase according to the turning speed. The transition is really smooth for me now (with an encoder and a normal potty)
If you are able to compile Rack from sources you can use my branch and test the new feature, See #309 (I'd love some feedback 😉)
And you guys are the only ones who are doing this as far as I know. No one else seems to give a rip about 7-bit knob jaggies. THANKS A MILLION for your efforts. 🥇🥇🥇🥇🥇
Seems really strange to me this is not standard.. 🐙
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jonheal]

I’m new to Git and not a C++ programmer at all, but I attempted to follow the instructions for building. I’m not sure my instance built correctly. It runs, but with the scenario shown here, I’m not hearing smoother filter transitions when I turn the knob on the BCR2000. I have probably done something wrong. Also, plugging into the v/oct jack, the frequency still changes in the same stepping fashion. But maybe that is something that cannot be smoothed ...

[bontric]

I assume you used the master branch which does not contain the feature yet. However, you can easily get the patch by running the following command in your Rack folder:

git pull https://github.com/bontric/Rack-MIDICC-Fork 2017-10-bontric-midiCC-fix

afterwards simply run

make run

and you should have the patched version running.

[jonheal]

Holy moly! That’s as smooth as a baby’s pink little bottom! Well done, sir!!

--
Jon Heal
Have a nice day!

From: Ben
Sent: Sunday, October 29, 2017 4:33 PM
To: VCVRack/Rack
Cc: jonheal; Comment
Subject: Re: [VCVRack/Rack] MIDI interface revamp (#81)

I assume you used the master branch which does not contain the feature yet. However, you can easily get the patch by running the following command in your Rack folder:
git pull https://github.com/bontric/Rack-MIDICC-Fork 2017-10-bontric-midiCC-fix
afterwards simply run
make run
and you should have the patched version running.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jonheal]

No one on the planet has ever experienced such a buttery sweep through a software VCO’s frequencies using a hardware MIDI controller. As far as I am concerned, I effectively have a hardware Eurorack system. Very happy!!!

--
Jon Heal
Have a nice day!

From: Ben
Sent: Sunday, October 29, 2017 4:33 PM
To: VCVRack/Rack
Cc: jonheal; Comment
Subject: Re: [VCVRack/Rack] MIDI interface revamp (#81)

I assume you used the master branch which does not contain the feature yet. However, you can easily get the patch by running the following command in your Rack folder:
git pull https://github.com/bontric/Rack-MIDICC-Fork 2017-10-bontric-midiCC-fix
afterwards simply run
make run
and you should have the patched version running.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[bontric]

No one on the planet has ever experienced such a buttery sweep through a software VCO’s frequencies using a hardware MIDI controller. As far as I am concerned, I effectively have a hardware Eurorack system. Very happy!!!

Thanks, very glad to hear this works so well for you! Did turning a knob sometimes feel unresponsive to you? Especially slow motions might seem a bit like they are slowly transitioning. If you don't get this feeling, it would be great news, since I'm a bit worried that people might complain about that. (For myself this works great as well, but it's a bit difficult to have an objective opinion as the developer..)

[jonheal]

If it felt even slightly unresponsive, it was negligible, at worst; and the benefits FAR, FAR outweigh minuscule sluggishness. In fact, I would refer to any perceived sluggishness as "dampening," because that makes it sound like it's intended to be there. :-)

This is a terrific improvement. Anyone who would complain about it is nuts.

EDIT: I played with it some more. I see no issue, whatsoever, with slow knob turning. If you really whip a knob to the right, and then back to the left, it can take a bit for the sound to catch up. This is most noticeable with a frequency sweep. But how often is anyone really whipping knobs around? You cannot control where you want to be on the knob anyway when you really whip it, so I can't see any real reason for whipping knobs around manually except to create a jarring effect, in which case, a bit of lag in the sound probably won't matter.

--
Jon Heal
http://www.theheals.org/
Have a nice day!

On Oct 30, 2017, at 9:51 AM, Ben [e-mail] wrote:

No one on the planet has ever experienced such a buttery sweep through a software VCO’s frequencies using a hardware MIDI controller. As far as I am concerned, I effectively have a hardware Eurorack system. Very happy!!!

Thanks, very glad to hear this works so well for you! Did turning a knob sometimes feel unresponsive to you? Especially slow motions might seem a bit like they are slowly transitioning. If you don't get this feeling, it would be great news, since I'm a bit worried that people might complain about that. (For myself this works great as well, but it's a bit difficult to have an objective opinion as the developer..)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jonheal]

If you are really worried about it — and I don't think you should be — and if you are easily able to encapsulate all of your changes so that one slide switch could enable or disable them, then maybe said switch could be added to the module to turn "smoothing" on or off. (Although no room for it, really ...)

But again, I think this is a very beneficial change that most-to-all hardware interface users would welcome.

[bontric]

Cool, thanks for the feedback. I think I'll leave it the way it is for the next version and see if we get more feedback.

If you are really worried about it — and I don't think you should be — and if you are easily able to encapsulate all of your changes so that one slide switch could enable or disable them, then maybe said switch could be added to the module to turn "smoothing" on or off. (Although no room for it, really ...)

Maybe I'll add a midi configuration module in the future which would allow very detailed configuration for each midi device. This way, the "normal" user is not confronted with the settings but if someone wants/needs more detailed settings it can be archived easily. I'll add that to my mental road map for the next version, since it's also a useful tool for me to try out different settings without re-compiling each time.

[bontric]

• Add Trigger Output to Midi-To-CV

(As suggested in #521)

[AndrewBelt]

So after playing with it for a while, I believe that the MIDI clock to trigger module should not include a clock divider. A single clock should be all that's needed. I think it should fixed to 1/16. I imagine Wes would feel the same when the panels are redesigned in the future. Instead of Continue, I think that Start, Stop, and Reset should be used instead. Start would trigger when restarting or continuing, and reset would trigger when restarting.

But for now, I wouldn't even work on these until #375 is finished.

[bontric]

So after playing with it for a while, I believe that the MIDI clock to trigger module should not include a clock divider. A single clock should be all that's needed. I think it should fixed to 1/16. I imagine Wes would feel the same when the panels are redesigned in the future.

I guess a clock divider/multiplier could also always be implemented as a separate module easily so there is no real need to have it in the core modules.

Instead of Continue, I think that Start, Stop, and Reset should be used instead. Start would trigger when restarting or continuing, and reset would trigger when restarting.

Okay, implementing this is no problem. Additionally, by removing the clock dividers the module is going to be way simpler.

But for now, I wouldn't even work on these until #375 is finished.

Yeah, I think I'll add the Midi-Out multiplexing wrapper soon, but for the rest I'll have to see when I find the time. (Implementing the rest should be rather simple though..)

[AndrewBelt]

I guess a clock divider/multiplier could also always be implemented as a separate module easily so there is no real need to have it in the core modules.

Yup, exactly. By the time the future MIDI core modules are added, we should have a clock multiplier/divider.

You might even wait for #375 before writing the multiplexer, since the multiplexer would be built into that widget instead. Basically all the MIDI driver (and audio driver) stuff would be handled by the widget.

[bontric]

As discussed in #535 The Quad-midi module should have an optional legato mode. (I'm unsure whether it might also be possible to implement this with an envelope module but I guess implementing this for the Quad-Midi module would be a quite small addition anyways) (Not doing this see #535 )

[Flowstoner]

@bontric before trying to implement it, is there any step in the direction of implementing the MIDI-OUT class, so as to have complete management from your MIDI-IO class wrapper?

[bontric]

@bontric before trying to implement it, is there any step in the direction of implementing the MIDI-OUT class, so as to have complete management from your MIDI-IO class wrapper?

@Flowstoner Implementing the midi out wrapper is rather straight forward since it doesn't require any special handling except for making sure that the device objects are shared properly. The reason I haven't done this yet is because I'm waiting for #375 to be finished. @AndrewBelt said he'll finish this within the next day so I can add the midi out wrapper tomorrow as well.

[bontric]

@AndrewBelt Just wanted to note that I'll be gone for the next week and won't be able to do any work on this.

[maxmcorp]

I cannot seem to find any notice of it, but it seems to me that the MIDI-to-CV is missing a retrigger output. It should be generated at every note on event. The envelope generator has a "retrig" input, but there is no way to trigger it from the MIDI-to-CV. That makes playing Rack from a midi controller difficult.

I got fat and slow fingers so I often dont release a key before pressing the next one. Having it all playing legato makes for a lot of mute notes.

[DavidJameson]

Is there in fact a CV-to-MIDI module implemented anywhere?

[AndrewBelt]

@bontric Sounds good. I've been late on development, but finishing #375 is the current task.

@maxmcorp I suggested it above. https://github.com/VCVRack/Rack/issues/81#issuecomment-352733977

@DavidJameson No, not yet.

[derMars]

Hello,
are there any news to the MIDI-Out thing? I bought the PulseMatrix and I would really love to trigger some of my external gear with it. Are there any betas I could join or any info about a release? Thanks.

[AndrewBelt]

It will be included in Rack 0.6.
The latest source is the master branch of Rack, but PulseMatrix doesn't build for it until Rack 0.6 is released.

[derMars]

Thanks Andrew, guess I have to wait then. I'm really excited for this. Kepp up the good work!

[bontric]

@AndrewBelt Just saw the new design for the audio and midi interfaces, they look great!
I guess I could start working on the output modules, or is this still a WIP?

(Small Note: The Midi-Trigger module is titled "Midi-CC")

[AndrewBelt]

I'll take it from here. No need for more PRs on this.

[Coirt]

Text colour/size temporary? Very hard to read imo. The yellow and the black is okay I guess but the weight of the text makes it hard to read.

[AndrewBelt]

@Coirt pinging @milholen

[SubitusNex]

@AndrewBelt these upcoming features seem great, lots of potential. Any plans for a cv-to-cc module as well? In a virtual modular those could really help extend patchability with external hardware.

For example looking at the novation circuit, it could be used to change sessions, patterns, samples, or even modify patches within the external - so I kind of see those cv-to-cc as simplistic output patch cables.

Anyways thx for all the great stuff.

[AndrewBelt]

@SubitusNex Still not sure about any of the Rack-to-MIDI modules. I have ~40 to-do items for March 21, but surprisingly I'm ahead of my estimated completion date. But of course anything could come up and take a few days longer than it should be, leaving no time for the extra Core modules. Fortunately, these are modules that can be added without breaking ABI, so they could arrive in a 0.6.* version.

[SubitusNex]

I didnt expect it immediately for 0.6, just glad to hear it.

Em 03/03/2018 09:27, "Andrew Belt" [e-mail] escreveu:

@SubitusNex https://github.com/subitusnex Still not sure about any of
the Rack-to-MIDI modules. I have ~40 to-do items for March 21, but
surprisingly I'm ahead of my estimated completion date. But of course
anything could come up and take a few days longer than it should be,
leaving no time for the extra Core modules. Fortunately, these are modules
that can be added without breaking ABI, so they could arrive in a 0.6.*
version.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/81#issuecomment-370133756, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AiRiY2peM65vLEv2iuApr63PAayVCnFhks5tamHngaJpZM4PYFj1
.

[VSpellbound]

i need CV to MIDI so much.
the idea of sequencing and controlling hardware synths & vsts in daw via vcv rack blows my mind

[AndrewBelt]

Yeah, the possibilities are endless.

[AndrewBelt]

@bontric One question: I'm using exponential smoothing for MIDI CC with lambda = 1/100 s, and it seems to work fine. With all of my MIDI controllers, I can't convince myself that the method is "sluggish", yet it solves the discrete jumps in pitch or filter cutoff that prompted the smoothing. What were the problems exactly with exponential smoothing that caused you to implement the alternate smoothing algorithm?

[Coirt]

@AndrewBelt might be worth posting on FB for others to test who don't have the same Midi Controllers, no?

Have an old novation Remote 25 LE midi controller, the contacts on the pots could probably do with some contact spray maybe if they are jumping, mine jump violently. Possible due to corrosion on the pots.

[bontric]

@bontric One question: I'm using exponential smoothing for MIDI CC with lambda = 1/100 s, and it seems to work fine. With all of my MIDI controllers, I can't convince myself that the method is "sluggish", yet it solves the discrete jumps in pitch or filter cutoff that prompted the smoothing. What were the problems exactly with exponential smoothing that caused you to implement the alternate smoothing algorithm?

At that time I did a mostly trial and error approach with two different types of controllers. I'm not exactly sure anymore why I decided on the linear smoothing but I think it has to do with Encoders vs. Potentiometers and how the Controllers sends messages.

(For reference: I used a Novation Circuit (encoders), a Arturia Beatstep (encoders) and a self made Midi controller with potentiometers ).

To test this, try to debug your Midi messages. As far as I remember some controllers send a Midi message for (almost) every step regardless of the speed you turn it. Others (especially encoders) have larger Jumps the faster you turn it. This affects the smoothing and I guess I came to the conclusion that Linear worked the best for me.

However, I took a very practical approach and there are multiple parameters to tune. I can imagine that using a different lambda might solve the problem I encountered at that time with exponential smoothing.

[AndrewBelt]

Are the modes rotate, reset, and reasign an ad-hoc standard? I'm implementing MIDI-4 today (previously known as QuadMIDIToCVInterface), and I can't imagine exactly what they do. Here's my guess, if I had to make them up myself.

• Rotate
  
  
  
  • If you play monophonic MIDI, each note will choose the next channel.
  
  
  • If you hold 2-4 keys, it tries the next available channel
  
  
  • If more than 4 keys are held, it kicks off the oldest note
  
  
• Reset
  
  
  
  • Same as Rotate, but it chooses the lowest available channel, not the next in the cycle.
  
  
• Reassign (is this the usual name?)
  
  
  
  • Same as Reset, but if an old note is released, the newer notes shift upwards.
  
  
• Unison
  
  
  
  • Uses the mono synth algorithm, all channels are equal.
  
  
  • Useful for quickly switching MIDI-4 into mono mode, with your four connected oscillators. Useful for tuning.
  
  

[dllmusic]

In my module MIDI Poly 16 I did it this way:

• Restart (or Reset) : The incoming note always use the first available voice channel ...(just clarifying that channel is not MIDI channel)
• Rotate : The incoming note always use the next channel.
• Recycle : Very similar to Rotate but the incoming note repeats the highest index free channel instead of going to the next one...this is useful when playing a repeated note held with sustain pedal (the channel will not rotate)

About the Reassign... usually each voice stay locked to its own output, but actually shifting outputs when releasing notes could be interesting, for example when using different waveforms or portamento.

For voice stealing (playing more notes than available) it's always rotate (replacing the oldest one)

For Mono I have 3 options: Lowest ,Highest or Last played notes.

[AndrewBelt]

Anyone want to help me finish MIDI-4 with a PR? I can't think of good algorithms off the top of my head for Rotate, Reset, and Recycle/Reassign. They need to handle the sustain pedal properly and use minimal data structures. The relevant code is in https://github.com/VCVRack/Rack/blob/master/src/Core/QuadMIDIToCVInterface.cpp#L69-L160

[dllmusic]

I'll check this out ...

[dllmusic]

Working on this later today...
I will send you a PR tomorrow

[dllmusic]

Andrew. I'm almost done with this....all poly modes are working ok. I still need to deal with the pedal... I didn't have too much time available so I will PR tomorrow... thnx

[AndrewBelt]

Excited to see it!

[dllmusic]

Just created the PR.
https://github.com/VCVRack/Rack/pull/842
I also sent the file and a CVC patch to your FB

[jonheal]

The MIDI smoothing that Bontric incorporated (noted about halfway up this thread) seems to be gone in version 0.6. :-(

[AndrewBelt]

@jonheal Yeah, we had a short discussion about what it does, and I couldn't tell that it made a major difference, so I didn't port it when I rewrote the MIDI interfaces. Still not sure why he added it, maybe you could explain?

[jonheal]

Andrew, it was a fantastic feature. the 128 MIDI steps are extremely obvious, jarring and distracting when turning an encoder slowly (and I assume a pot, as well) to control a filer sweep or any other control that alters the character of the sound.

I'm BEGGING you to put it back in.

--
Jon Heal
http://www.theheals.org/
Have a nice day!

---

From: "Andrew Belt" [e-mail]
Sent: Thursday, March 29, 2018 7:21 AM
To: "VCVRack/Rack" [e-mail]
Subject: Re: [VCVRack/Rack] MIDI interface revamp (#81)

@jonheal Yeah, we had a short discussion about what it does, and I couldn't tell that it made a major difference, so I didn't port it when I rewrote the MIDI interfaces. Still not sure why it was better.

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[bontric]

@AndrewBelt Huh? I was assuming you where questioning the parameters to use for the smoothing, not the smoothing itself.

There is a clear audible difference between using smoothing an not when turning a knob

we had a short discussion about what it does, and I couldn't tell that it made a major difference,

Still not sure why he added it,

This has been discussed in this thread

[jonheal]

@bontric I find it even more obvious when turning a knob slowly. Not only are the individual 128 steps now very audible, but for my encoders, they kind of gallop, step-step ... step-step ... step-step.

[bontric]

@jonheal yes, you are right. I typed that too fast ;)

[AndrewBelt]

There is a clear audible difference between using smoothing an not when turning a knob

Well, the smoothing was changed to exponential with lambda=1/100s, not removed. @jonheal is saying that parameters don't appear to be smoothed, yet in my tests it sounds fine.

[jonheal]

If you want, Andrew, I will record an example of slowly sweeping through a filter with an encoder.

--
Jon Heal
http://www.theheals.org/
Have a nice day!

---

From: "Andrew Belt" [e-mail]
Sent: Thursday, March 29, 2018 12:15 PM
To: "VCVRack/Rack" [e-mail]
Subject: Re: [VCVRack/Rack] MIDI interface revamp (#81)

There is a clear audible difference between using smoothing an not when turning a knob

Well, the smoothing was changed to exponential with lambda=1/100s, not removed. @jonheal is saying that parameters don't appear to be smoothed, yet in my tests it sounds fine.

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[AndrewBelt]

Sure, actually.

[jonheal]

OK, now I am not sure. Admittedly, the first time I tried it out in .6, I may have given it an extreme test, which was self-oscillating a filter. I just now tried it again under "normal" conditions and it seemed smoother. The recording linked below contains three sets of sweeps, two sweeps each. The first set is the VCO-1 saw feeding into the VCF, sweeping the frequency knob with no resonance. The second is also feeding the VCO-1 into the VCF, but with full resonance. The resonant overtones are steppy. The third is the VCF self-oscillating with full resonance. Very steppy. Maybe the huge range of frequencies that the resonating filter sweeps through is just too much territory to smooth out over only 128 "real' steps.

https://1drv.ms/u/s!Asy9MQ3kIBNQgbd22yS8exfFNFQA3g

Patch:
https://1drv.ms/u/s!Asy9MQ3kIBNQgbd34PWuXbYO9YC00g

Many artifacts in my recording. Not sure what's going on there except that I have ann old, crappy computer.

[bontric]

@AndrewBelt I just realized where all the confusion is coming from. All the time I was assuming we are talking about my Smoothstep (MidiIO.hpp#L106) implementation. There is a major difference between this and the _exponential smoothing_ you are currently using.

Smoothstep additionally uses the difference between the _start_ and _target_ value (delta) to set the amount of steps (lambda) it takes to change from the _start_ to the _target_ value. (When used in the default DELTA mode)

    void set(float start, float end, int l = 1500, TransitionFunction t = LIN,  TransitionMode m = DELTA, bool reset = true) {
        this->start = start;
        this->end = end;
        this->delta = end - start;
        this->t = t;

        if (reset || x >= 1) {
            this->x = 0;
        }

        switch (m) {
        case DELTA:
            /* If the change is smaller, the transition phase is longer */
            this->step = delta > 0 ?  delta / l :  -delta / l;
            break;
        case CONST:
            this->step = 1.0 / l;
            break;
        }

    }

I ended up with this solution since I couldn't find a satisfying fixed lambda. Either turning a knob fast would lead to a way too slow transition (using a large lambda) or turning a knob slow would lead to a noticeable jump (using a small lambda). Hence I decided to use a variable lambda which is longer for smaller changes and shorter for quick changes.

[AndrewBelt]

Is there any way to satisfy https://github.com/VCVRack/Rack/issues/867 in a similar method to your nonlinear smoothing? Perhaps using the exponential processor, except if in - out is beyond a threshold, the state jumps out = in?

[bontric]

Is there any way to satisfy #867 in a similar method to your nonlinear smoothing? Perhaps using the exponential processor, except if in - out is beyond a threshold, the state jumps out = in?

As far as I understand that issue, it seems to me that a "disable" option for the smoothing would be the best option.

Perhaps using the exponential processor, except if in - out is beyond a threshold, the state jumps out = in?

I'm not sure whether that is a good idea, since the threshold would require a different value for different use cases. A simple On/Off switch for the smoothing is the better option in my opinion.

Different use cases and personal preferences are general issues when it comes to smoothing. That is why I tried to make the TransitionSmoother configurable with different curves (LINEAR, EXPONENTIAL, SMOOTHSTEP'), modes (CONST, DELTA) and transition time. These could be added as modifiers in the configuration menus of the midi modules in the future.

[Pandino]

I noticed that the RTRG output on MIDI-1 triggers not only when a note starts but, if a note is already playing, it triggers also when this second note stops. Is this by design? (Using VCV rack 0.6.0 on Windows 10, connected to an Akai MPKII mini)

[jonheal]

It is not clear to me if anything was decided here. Is Bontric's Smoothstep (MidiIO.hpp#L106) implementation still part of the project?

[ghost]

Feature request: support for 14-bit MIDI CC values? Someone brought that up on the Facebook. Sadly I don't (think I) have a controller that supports this, so I can't test.

As for testing: You can always write a simple test setup with Processing and one of it's Midi plugins and send that through Loop Midi or a similar virtual Midi cable. That's what I did in the past in such cases.

A tool like Lemur on a touch device can also help there.

As for testing MPE: I can highly recommend the Roli Seaboard Block. Affordable and very well thought out. Native MPE support would be very very much appreciated :-)

[norahgrey]

guys, I'm really new to this, as much that I can't make sense out of most of the things posted in this thread, but I guess I gotta learn... I have this problem with rack not recognizing the output of my keyboard midi interface, id be glad if someone explained to me in simple language how I can fix it. id explain a bit more, see I've set my midi cv to core midi: usb midi interface, tho I only get the frequency sent from the keyboard I have and it doesn't come back to the keyboard. I tried to change the audio-8 thing to the interface but there is no choice, only my Mac built in output/input. please let me know how I can fix this.

[Coirt]

@norahgrey you will get far more responses on the official community forum >
https://community.vcvrack.com/

Try to post some screenshots of how you have the patch setup there.

[AndrewBelt]

Closing since all features in the first post are added.