Yes, the licensing sequence makes sense. I just wasn’t expecting that. Other information is on the way. That C4104 update was for 45 song conversions and there were only two problems. Pretty good batting average. Thanks for looking.
You have mail
Still working through these range mapping bugs so no build today, but I have added this…
When mapping a switch or value condition to a command you can now choose exactly when the target should be invoked:
- If True - any incoming value that matches the condition invokes the command
- If False - any incoming value that doesn’t match the condition invokes the command
- On True Edge - when the value transitions from False to True
- On False Edge - when the value transitions from True to False
- On Either Edge - when the value transitions in either direction
- Repeat While True - auto-repeat invoke the command while the condition is true
- Repeat While False - auto-repeat invoke the command while the condition is false
This combines the old “Inverted” and “Auto-Repeat” settings along with a few more possibilities and should provide a fix @easteelreath issue of try to map any note press to a command (transport play).
Thanks… I’ll check it out. (might be a few days as I’ve got a bit of backlog of things to look into).
Hi @Organist
I’ve been looking into this issue with unknown plugins and believe it’s related to this item from build 4063:
I’ve been able to reproduce the exact thing in the insert plugin window however only when reverting to build 4062 after running 4063 or 41xx - and that’s expected because the plugin database format changed in 4063 in a way that 4062 doesn’t understand.
Can you confirm you’re getting this in 4104 after upgrading from 4062? Seems the problem should only happen when downgrading from 4104 to 4062.
Brad
Thanks for confirming… yes, that’s expected behaviour. When downgrading to pre-4063 you need to run a full plugin scan again to restore the plugin database.
To clarify the difference between these binding points:
- Load by Program - loads a program from the set list with program number matching the entered value for the song in the set list. eg: a Load by Program with program 23 will load that song from the set list no matter where it is in the order.
- Load by Index - loads a song by its position in the set list. eg Load By Index with index of 2 will load the second song in the set list, regardless of its program number.
Load by Program is better when you want to load a specific song. Load by Index is for when you want to cycle through your set list, or otherwise use the order of the songs in the set list. If switching to Load by Index fixed your issue then you must have all your set list songs ordered sequentially and starting at program 1.
As for the bindings there was a couple of issues here with the upgrade where this type of binding was upgraded to a value range mapping. ie: trying map the program number range to the full set of available program numbers. Basically it was broken and needs a different type of mapping - a direct mapping.
I’ve addressed this by making the mapping mode selection smarter such than when mapping to a index, program number or banked program number target, it will choose direct mapping mode. This mirrors functionality of the old bindings system, but more explicitly.
Also, there’s now a concept of “Automatic” mapper where Cantabile chooses what it thinks is the most appropriate or likely mapping mode. Or, you can explicitly choose the mapper you want:
eg: because this target is expecting a program number, it’s doesn’t (usually) make sense to do range mapping so the preferred automatic mode is “direct”:
eg 2: compare to if you mapped a program change to a gain setting. In that case you almost certainly want a range mapping:
This was an oversight where the new mapper always wanted to check for a value condition when mapping a value to a command. I’ve addressed this by adding a new value condition “Always” and an invoke mode “If True” (which is hidden when Always is selected since it’s the only thing that makes sense).
So, that binding should now upgrade to this:
These improvements will be in the next build, but still looking at other issues… stay tuned.
Hi @easteelreath,
Regarding your foot pedal rack, as you suspected this is related to the incorrect mapping of binding range to “+30dB”. Old builds were upgrading your rack to this:
but should have been upgraded to this:
The special value “(Max)” means the max value supported by the MIDI control curve (which is about 7.3 for the default curve). Basically your mapping to the gain setting was getting clipped back to that 7.3 which reduced your output range to 0-54ish.
However… the fix for the Max/30dB bug was fixed in 4104 so it should work in 4104 if you upgrade from pre4100 file (as opposed to opening in 4104 from an earlier 41xx build). Did you originally upgrade this file in 4100-4103?
Testing here in the next build, upgrading your original rack seems to work fine. Using the already converted rack doesn’t (but can be fixed by changing all those 30dbs to max)
I’ll check when I get home. Drive was “Reflected” back to C4062 yesterday, so t=0 is ready for comparison. Excuse my brevity as I’ve only got a phone. On a side note, I was as Duran Duran in Nashville last night. This Cantabile crowd seems more like a Rick Wakeman bunch, but I always liked Nick Rhodes.
Well, good musical taste (for lack of a better word, atm) is good musical taste, whatever the number of notes-per-second. And Rhodes has good musical taste (as a matter of fact I have Rio on my playlist right now, together with IQ and a lot of other prog stuff).
Going back in topic, unfortunately this time of the year I am so busy at work that I don’t have any time left for playing…so i didn’t have a chance to try the new 4100 series. On the up side, I will benefit from the debug of the other members of the community (not that I am doing that on purpose…).
Gabriel
I upgraded from C4062 directly to C4104.
When the program changes were not working, I had already sorted the set list and reassigned program numbers within the set list in C4062, so either Program or Index song load bindings would work the same way. In C4104, the midi program change did nothing in Program binding mode. No songs were loaded. I understand about program vs. index, but when the set list is sorted and “Re-assigned Program numbers” starting at 1, program OR index selection should be the same.
When I see C4105. I’ll try again with the Transport binding and the Foot Pedal Rack.
Eric
Hey @Torsten,
Thanks for sending the files… checked it out this morning, found the issue, will be fixed in next build.
fwiw: the case where this happened was the second time a MIDI source binding is manually invoked. When invoked from the actual MIDI source there was no issue. The exception was an internal sanity check to ensure an async completion callback was invoked - which it wasn’t from the test button. ie: this was deliberately inserted exception designed to catch an otherwise silent bug - which it did
Fix will be in 4105, coming soon hopefully.
Brad
4105 is up now: (see first post in this topic for release notes)
cc: @dave_dore, @Torsten, @easteelreath,
C4105 Comments:
I’d upgraded the license on my practice rig for C4062, so upgrade to C4105 required no new license.
Program/Index Song List works now for MIDI Program Change to song list loads.
Transport play bound to note on/off works now.
Foot pedal rack still does not work. C4105 converted to the -inf and max ranges, but foot pedals are still flaky. The C4105 rack looks like what it should look like in a previous post. As a pedal is depressed, CC11 is Zero, then jumps to 104, and finally climbs to 127. The footpedals are working because a midi filter of CC14/15 to CC01 (Kemper Wah) works fine - that did not work in C4104.
CC14/15 are mapped to Rack Output Gain. The Output gain can be mouse-dragged back and forth and the CC11 is output correctly to the Kemper with a few range problems.
There appear to be scaling issues with the Rack Gain. Max is supposed to be +30 dB, but using the bass pedals on/off, the max is +27.2 dB. C11 is output 127 for this situation. Dragging the gain dot with a mouse only goes to +7.3 dB. CC11 max is only 115 with the mouse.
I’ll keep fishing for details with C4105, but the scaling issues catch my attention.
And now 4106 is up because I forget to fix one small issue.
The MIDI target binding point when configured to send program change or banked program change can now either send a program change number that’s sent to it, or a program number that’s configured in the target itself.
To send a program number that’s sent to it you choose “Mapped” in the program number field in the target:
Unfortunately previously you couldn’t choose “Mapped”, but in 4106 you now can and the bindings should upgrade correctly to use it.
Thanks for testing this - glad the other issues are resolved.
Not really sure what’s going on here. When I tested with the rack you sent it seemed to work fine. Are you still seeing +30dB in places - I don’t think you should be.
Any info you can figure out on how to reproduce this and/or why it’s happening would be useful.
Brad
Thanks for the update. What I see are range problems when transposing from a CC0-127 to the Rack Output Gain which should now be -100 dB to +30 dB. I thought the min was -80 dB, but I’m seeing some -94 dB when I drag the ball. The the 30 dB is never shown on the scale. If Rack Gain is changed by the on/off note, rack gain goes to +27.2 dB and the dot is off scale (no rack gain dot is visible). When the mouse is used to drag the rack gain dot, the max is only +7.3 dB and CC11 is output at 115 and not 127. I can’t get screen shots because the numbers are not persistent when the mouse moves away to catch a screen shot.
Tomorrow I’ll try a “from scratch rack” and see what happens.
I had one of these recently.
Hey guys,
Just so you know, this afternoon I got a bug report from @dave_dore that highlights two issues:
- The binding update mechanism doesn’t handle updating exported states on bindings. This is an oversight on my part and I’ll get it fixed. The result is an exception when loading.
- The first problem is highlighting a second problem in the error recovery after failing to load a song where the UI is left blocked (looks like an unresponsive hang).
The second problem has been there for some time but not really an issue unless a song fails to load in a particular way. Since Cantabile’s currently in a very experimental state and going through a stabilizing period anyway I’m going to rework of the way song load/activation is done. It might adversely affect stability for a build or two but now seems a good opportunity to address this.
Brad
And the result was …. ?
Back OT, glad to see good progress being made shaking the bugs out of this large change. Once I have my gig out of the way a week Sunday, I’ll give the latest version at that point a go.