Problem with midi control cc66

[humphrey]

Good evening community,

at the moment I have a serious problem that really drives me nuts. During the last weeks I have been fiddling around with some midi hardware components and tried to integrate these into cantabile with total recall capabilities.

To do so I tested several solutions to reflect the settings of the hardware inside cantabile, store them in host automation parameters and recall them when calling up a new rack state and finally song of course.

All this works well so far. My latest attempt uses simple audio routings where I misuse the audio
fader as memory element, indicator and control unit. Wrapping several of thee into a rack does the trick.

My problem occurs when it comes to the midi control parameter CC66 (sostenuto). Whereas this works flawlessly when simply selecting different rack states by hand I get a strange effect when putting this rack into songs and switch from one to another.

As long as CC66 is not part of the parameter set
everything is fine. If CC66 is active the stored value is correctly sent but followed by a second
instruction CC66 = 0 each time (independently from the stored value).

I tried several things to get rid of this effect (f.e.: I changed the control value for the input signal from
66 to 67 with a midi filter and reverted it back on the output of the rack) without any success.

It seems that cantabile takes note if CC66 is sent when switching songs and persists in adding CC66 = 0 each time (seems to happen outside the rack).

I had a look inside the background rack but found
neither routings nor bindings being capable of producing something like that.

So, my question: any ideas? Any help warmly welcome

Thanks and regards, humphrey

[dave_dore]

seems to happen outside the rack

Hi Volker,

Were you able to get a MIDI monitor look at the rack MIDI output to verify only the CC66 with a value other than zero was there? Have you compared it to the target destination (rack or port) ?

Just wonder what all is connected here and whether there are any bindings or onload engine restart bindings …

Dave

[humphrey]

Hi Dave,

for test purpose there is only the rack connected to a midi controller (B4D) on midi in and a midi out port conneted to midi out of the rack (just to be able to track with midi monitor).

The rack consists of 19 audio routings from audio in to audio out of the rack each. This function is not used for anything - I only needed the faders to create bindings.

For each route I created 2 bindings:

1. Rack midi in for a certain CC channel to the fader gain
2. fader gain to the same CC channel to rack‘s midi out

This way the rack faders are able to indicate the CC values received, store them to rack states and recall them if rack state is changed.

Atm I realised these:

1. CC12-20 Ch1
2. CC12-20 Ch2
3. CC66 Ch1

As you may have already realised this is a part of the CC channels for a hammond expander (HX3). 1) and 2) represent upper and lower drawbars whereas CC66 is used for perc on/off (and yes: quite some channels are still missing).

With this setup I tracked rack‘s midi out and these were the results:

1. calling up different rack states by hand: 19 CCs sent => o.k.

2. creating 2 songs wirh the rack inside calling up different rack states: 19 proper CCs sent followed by a CC66 = 0 => problem

3. creating 2 songs wirh the rack inside and first 18 CC channels disabled calling up different rack states: 1 proper CC66 sent followed by a CC66 = 0 => problem

4. creating 2 songs with the rack inside and only one of the other CCs enabled calling up different rack states: 1 proper CCs sent NOT followed by a CC66 = 0 => o.k.

Btw: this problem consists since weeks. I meanwhile have the 3rd solution running (first was based on Blue Cat Audio Remote, second a Linked Rack with Embedded Racks inside) that show the “CC66” effect. At least my estimation is the problem is sitting in front of the screen and running into the same bug again and again,

:HX3 Testrack mit Routings.cantabileRack (159.4 KB)

Hope I could clarify a bit,

regards, humphrey

[humphrey]

Hi,

additionally I attache a screenshot of 2 midi monitor outs taken from 2 songs.

The left clearly shows that sustenuto is set to 127 (which is the stored value) but than last instruction is setting cc66 back to 0 (which should not happen).

Right monitor is showing results for the other song. Here the stored value already was 0 but also in this case a final cc66 instruction follows.

Btw: rack was completed meanwhile for all midi instructions but the problem remains the same. Enhenced rack attached,

Regards, humphrey

HX3 Testrack.cantabileRack (274.2 KB)

[humphrey]

Edit:

meanwhile I slowly seem to get my head around this. My guess was this functionality could be some internal mechanism of cantabile and realised by design. So I tried this settings on a different PC with the exact same results.

Next I asked myself what could be so extraordinary for CC66 and came up with the idea that probably something special is going on for pedals. So I had a look for several other CCs and only for CC64, CC66 and CC67 this effect occured.

In consequence I was also able to initiate the CCxx = 0 by only implementing a binging firing CC66 on song load. This really initiated the effect - but - with the CCxx = 0 at an earlier time than the new one (which would be o.k. probably). It looks like an automatied mechanism granting released pedals aufter song switching.

What I cannot explain is the fact that CCxx = 0 is fired AFTER the CC instruction when coming from a rack.

Maybe @Brad would be so kind to jump in to enlighten me.

Kind regards, Volker

[dave_dore]

Hmm, it may be @brad may have put some safety to clear notes and common pedals on song loads to clear any possible ON messages not dealt with. Sounds like it anyway after hearing your other tests you ran. Good digging Volker I checked your racks here and they do the same thing with CC66. As I said I the song loads senses that CC66 may be stuck and clears it with a zero message so that tracks with your findings too. BTW can you use different CC numbers from your source controller to get around this?

Best,

Dave

[humphrey]

Yep, not on the direct way but as dirty hack.

I had a little “home project” running during the last weeks as it came to my mind to set me up the “ultimate” hammmond clone". The HX3 expander (Keyboardpartners) was already there but this lacks concerning overdrive and leslie. So I decided to spend some money and get me a ventilator II. This combination sounds teriffic (at least for me).

The only downside was vent cannot be controlled by midi (so no total recall, bad integration into cantabile). So did a deep dive into its schematic, implemented some modification and added an arduino board in an external box to it. Now I have a “midi ventilator” available

As the arduino already had a midi in and out I now can use it to map another CC (in this case I took CC89 - dunno why I took exactly this) to CC66, This way I can keep CC66 out of the rack and cantabile obviously doesn`t “see” it any more. Works flawlessly (but still a hack of course),

Kind regards, Volker

[dave_dore]

Hi Volker,

I put my mind on this and came up with a workaround using MIDI filters in the initial MIDI ports both in and out in the following way.

First edit or replace the bindings in the rack so they work off of say for example CC 63 instead of CC 66 sostenuto. But any non popular CC number you want would do of course. I had to delete the gain slider binding on the input route slider itself to change it completely right (to remove all references to CC66 from the rack json file). and then your bindings in the rack for the perc switch that was 66 are now 63

Then in the MIDI ports area you could put a filter on the B4-D MIDI port input to convert CC66 to CC63

and place a filter on the B4-D MIDI port out that converts CC63 back to CC66

It might not be what you want but it does address your issue I think and I hope it helps …

Best Wishes,

Dave

[JimboKeys]

I haven’t looked into this issue at all, but i wonder if some recent changes might have introduced this problem (e.g. Build 3647 “Fixed - some circumstances where held notes not released when switching songs”). Might be worth installing an older build and see if the problem is still there.

[humphrey]

Hi and thanks for responding @dave_dore @JimboKeys and sorry for responding so late.

Unfotunately we had a spontaneous meetig with our neighbours which bound me to „very important“ things and yes: there was quite some alcohol in the game (of course not neglecting safety distances due to Corona!).

The downside is: it will take till tomorrow to get my head around your proposals. But I will definitely respond tomorrow.

Meanwhile: thanks a lot and have a nice evening,

kind regards, Volker

[humphrey]

O.k. head has normal size again😉

@dave_dore: at first glance your proposal seemed to be something I meant to have tried some time ago - but yep: it is always useful to be precise and finally I saw this little difference. You placed remapping into a midi filter inside definition of a virtual midi port instead of rack output and that exactly nailed it - good work!

Even though remapping inside my arduino also fixed the problem your method is superior as the hardware units can now be operated in stand alone mode (means no cantabile, just the organ, controller and keyboard). Thanks alot!

@JimboKeys: I did a first test by rolling back to 3645 but this was not successful so far. But it could very well be that changes were introduced at an earlier time (or just me making a mistake?). Weekend arrived and I have some time to do some further investigations.

@brad: it would be nice to understand what exactly is happening here. I can probably understand that you tried to fix some downsides of real keyboards(?).

What I definitely don‘t understand is the reason why the signal for disabling a pedal enabled in a song seems to be sent „after“ sending new pedal information of a new song (or am I missing something?). A short comment would be great😃.

Have a nice werkend, regards, Volker

[Dave_C]

Now I have a “midi ventilator”

+1 for the Ventilator II. I was using this for a while with a Yamaha reface YC. I’ve since moved to software organ/rotary within Cantabile.

I’m also liking your idea of external microcontroller to MIDI the Vent. It’s getting me thinking to bring my Ventilator out of storage.

[humphrey]

Well, to be serious: it was a funny idea at first but I sometimes tend to push the envelope.
When I connected HX3 and Vent for the first time I suddenly had “that” sound I missed all the years. I don`t say “this is original hammond” (this is something specialists like Corky… may judge). I only say: I like it very much.

Next step was to simply control rotor speed by Midi. This was easy to achieve as there is a plug where you can easily connect to an external contoller. So far so good.

What was missing was the possibility to control vents “drive” (for every other parameter I can easily live with fixed values). This was the point where I had to decide to go into schematics and do modifications inside vent. It took me some time to make this decision as it meant to loose varanty!

So I finally have a vent that can be controlled conccerning drive, rotor speed and rotor on/off by midi.
The modification was done so that the vent is stil fully operative as used if the control box is disconnected (which was important to me). If you look from outside on the vent housing it seems completely unchanged. The hidden secret is I re-used the second audio-in as drive-control in.

All in all vent now has these capabilities:

• full standalone operation
• no damage of the housing
• control of rotor and drive by midi
• drive pot can take over control with Jump prevention functionality
• vent sends midi CC76 when drive pot on vent is moved

Btw: for me this was good enough but it should not be an issue to also control the other 4 pots f.e. by implementing a multi pin connector to vent or by implementing a contrioller inside vent (f.e, a teensy or nano might do the trick),

Should you be interested in some further information don`t hesitate to contact me.

Finally: is it neessary to be crazy to do such a project?? Not exactly but it is extremly helpful,

Regards, Volker

[Corky]

this is something specialists like Corky… may judge

Hey…Gotta do whatcha gotta do. I used a vent for awhile…it got me by for sure. I also used a VOCE Spin 2…it wasn’t great, but, again got me through. Had an E-MU B3 module for a couple of years before landing on NI B4. I definitely experimented several years to get a portabile B3 sound. Nothing like the real thing though, but latest efforts are pretty good! Apology to OP.

[Dave_C]

Very interesting project you have done Volker! High 5’s from me. Keeps the mind alive and juices flowing.

If I ever resurrect my Ventilator, I’m sure I’ll have a few questions to ask. I’m a retired electronics tech, so if the time comes, I’ll be able to converse with you at that level. I would probably start simple by MIDI’ing only the fast/slow/stop. That can be done 100% outside of the Vent from the remote jack.

Thanks for your interesting post.
Dave…

[Dave_C]

Had an E-MU B3 module for a couple of years

Eh Corky, I’ve still got a Proteus 2500 kicking around with the B3 module in it. Was kinda neat at the time. The raw sound of the Hammond was actually pretty good, but the fake wind-up and slowdown of the Leslie kinda sucked. It did sound a lot better with the Ventilator. But I have to agree with you, that you can’t beat the real thing. Thank heavens software has gotten pretty good at it now.

[Corky]

Hey Dave

Those days were very interesting. Loved the E-Mu stuff. I still have my Proteus MPS+ keyboard. I sold my B3, still had my Porta-B, but rarely used it. Eventually sold the Porta-B and my Leslie 122. I had no room to store them anymore. Started using the multi-sound keyboards, with expansion cards. I still have my Roland JV 1080 with all the expansion cards. The vintage keys card had good Hammond sounds, but the sampled Leslie wasn’t the best. Still, it was good for the time.

[Torsten]

I would probably start simple by MIDI’ing only the fast/slow/stop. That can be done 100% outside of the Vent from the remote jack.

Yup, I did that for the first Ventilator (and for the H&K Rotosphere) a couple of years ago. Built a simple box based on the MIDIbox platform that switches speeds based on modwheel commands it receives:

Happy to share the microcontroller code, circuitboard design, schematics, part list etc.

I got a bit crazy and integrated this in a MIDI merger / router for my two-keyboard setup to route MIDI data from my two stage keyboards to my additional on-stage devices (Ferrofish B4000, Ventilator, VoiceLive) and allow for Ventilator switching via mod wheel at the same time:

These boxes currently sit on a shelf and gather dust since I’ve moved on to a Cantabile-based setup. No more need for external hardware with B-3X for my Hammond needs…

Cheers,

Torsten

[Dave_C]

Holy cow! So much good talent on this forum. My Vent has been collecting dust for a couple years now too. I also have B-3X and Blue3 for my Hammond needs. So probably not necessary for me to go “Back To The Future”.

Sorry for getting off topic here with midi control cc66 thread.

I’m not ready to go crazy quite yet, but if I ever decide to torture myself, and get back into electronic design work, I know I’ve got lots of good talent on this forum to assist me if needed.

FYI - When I was working my expertise was industrial controls automation. It involved CNC troubleshooting, PLC and robotics programming / integration. That’s all behind me and now and liking retirement.

Thanks for offering to both @humphrey and @Torsten.
Dave…

[AlanMHughes]

An interesting thread. I too have used volume faders and rack states as methods to “remember” midi values for external devices. While it’s great fun and challenging to use Cantabile features to achieve the things we need , I’ve always thought Cantabile users would benefit from the provision of global midi value parameter objects for storing and retrieving.