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
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 ā¦
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:
Rack midi in for a certain CC channel to the fader gain
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:
CC12-20 Ch1
CC12-20 Ch2
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:
calling up different rack states by hand: 19 CCs sent => o.k.
creating 2 songs wirh the rack inside calling up different rack states: 19 proper CCs sent followed by a CC66 = 0 => problem
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
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,
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,
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.
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?
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),
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
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.
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.
@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š.
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,
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.
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.
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.
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.
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ā¦
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.
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.
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?
