It’s very close, but odd little bugs keep cropping up (as per the release notes above over the last couple of weeks). I’m planning to release to the official experimental release stream next week. (currently it’s only been released here on the forum).
ie: it should be ok, but test your setup first.
I’ve just released the first “official” build of the new binding system:
Of course, feel free to continue discussion about it here, or create a new topic if you think something is warranted.
I converted to C4127 and all 66 song worked with no issue. I use the WebUI server to show song notes on a floor video monitor, so root.folder is modified in my setup. I’m not sure what happens, but I always get an error about being unable to copy root.folder so I skip the file (I’d rather not have to copy the modified folder back anyhow). This is not particular to the C4100 series. Maybe this is by design to preserve the modified root.folder…
Works great!!!
Hi @easteelreath,
Thanks for the update - pleased to hear the bindings are working.
Regarding “Root.webfolder”: are you saying that you get an error during installation that it can’t be copied? That sounds like you might have modified the Root.webfolder file in Cantabile’s installation directory.
What you can do instead is put your Root.webfolder in the Resources folder - anything there will override what’s loaded from the installation folder.
See here for more:
Or, let me know if I’ve misunderstood the issue.
Brad
Yes, that’s what I’ve done. I’ll move to resource folder. Thanks.
I took the plunge and used 4125 in a gig last weekend. Some issues during set-up, but that was mostly related to two things outside Cantabile’s control:
Once the USB cable was replaced and the setup all loaded up, everything behaved flawlessly - including driving the lights for our show from Cantabile.
So for me: full steam ahead with 41xx!
Hey @Torsten,
Thanks for the update - glad it worked well for you.
Yep, I’m pretty much fully committed to 41xx now and all future development will be on this branch.
Brad
Once the system is converted to the new C41XX, does anything need to be done to clean out remnants of earlier versions?
Nothing “needs” to be done, but if you like to keep things clean you could delete the .pre4100 files.
One thing to note though: these files are only created once the old song/rack is saved. If you don’t save the file, it’s re-upgraded each time you open it. So unless you go through and manually save each song/rack you might find these files popup from time to time.
Personally, I’d just leave those files there until you’re 100% sure you don’t need to go back.
If they become a pain, let me know and I can add an option to not create them and/or something to clean them up.
Brad
I am running C4127, but none of my song files are saved to a new date. I also don’t see any .pre4100 files (I’m assuming that’s the file type). I have a feeling every time I load C4127, the files convert but I’m not saving anything. Even if I “Save All,” nothing appears to be saved. I exit, and do it again (Groundhog Day…)
That sounds odd. I’m not sure what’s going on with your setup, but:
If you use File → Save the current song or rack (what ever’s on view) will always be saved and the time stamp should be updated. If not, check you’re looking at the right folder/file.
If you use File → Save All, it always saves the current song file but only saves racks that are modified. (I think from memory)
Opening an old song/rack and upgrading the bindings, doesn’t mark the file as modified - so Save All won’t necessarily save those files.
There are other settings in File → Song Options and File → Rack Options that control what actions can mark a song as modified so these might be having an effect.
.pre4100 files will only be created if the file was last saved by a pre-4100 build. New files and already upgraded files will never create these files.
If you really want to check which build a file was saved by, you can open it in a text editor and search for “Build”. You’ll see something like this:
Hopefully this will help you figure out what’s happening in your setup.
Brad
I guess it’s OK as C4127 is loaded and all the songs are playing as expected.
My expectations were erroneous. I was expecting every songs/set/rack opened in C4127 to 1) backed up for the old C4062 as *.pre4100 file, 2) converted to a new format for C4127 and retain the *.cantabilesong/setlist/etc. extension, and 3) obviously have a new save date when updated. My original question was about removing the *.pre4100 files once the final jump to C4127 is made but I don’t see any *.pre4100 files.
Once gain, if I save a file in C4127, there is no *.pre4100 created in addition to the *.cantabilesong with today’s date. I was thinking that a C4062 songfile was incompatible with C4127 and had to be converted and saved, and a backup was created with a pre4100 extension. All of the converting/saving/backing up was triggered with a song load in C4127.
There is no “Build” string in either songs or sets, so I can’t determine what version saved the song other than by the date. Can’t find “4127,” either, in newly saved songs.
UPDATE: I did find the *.pre4100 files (two: Test Song file and the Background Rack so far). What threw me off was the file modify date had not changed, so they are not at the top of my date-sorted list. There is no “Build” text in the file to define C4062. I assume that the NEW saved files are now C4127 and are dated the new date of save. The OLD C4062 retained the old save date but now have a *.pre4100 extension.
I have a concern that if the C4062 file is not saved when loaded into C4127, the file will never change and will always be perpetually converted on load into C4127. Seems like I’d want to run a script to once and for all convert every file from C4062 to C4127 (and create the associated *pre4100 files in a designated directory) and totally cut the chord (HA!HA!). Maybe this is by design or not a big deal.
Am I right that if I make changes to songs, racks, setlists a. s. o. in v4 I can’t use it with v3 anymore?
Currently I still use v3 and make all changes there but always try it out with version 4 to make sure that all works properly.
Song and rack files saved in v4 won’t load correctly in v3. They’ll load but all bindings will be missing.
That’s possible. Let me think about it a bit and see if I can come up with a way to immediately update everything, but to be honest I think it’s better the way it is. So long as the upgrade is working correctly (which I believe it is now) keeping your songs in the older format until they’re modified isn’t that big a deal (except you’ll occassionally see .pre4100 files popup when you save upgraded files for the first time).
Then I’m good leaving it the way it is. The songs will eventually cycle through and be updated to *.41XX. I just had some preconceptions about how the songs would update.
Maybe this one of those stupid questions, but if a current C4062 file can be opened, converted, and played in C4127, why would C4127 save in a format that is not backwards compatible with C4062? Seems like the same file format for C4062 could be maintained…
No such thing.
Internally the new bindings are managed as three separate objects - a source object, a target object and a mapping object - and that’s how they’re saved/loaded.
In the old binding system there was a single binding object and it had all the settings for all binding types stored on it - it was a bit of a mess with some settings overloaded for different binding types etc…
When you upgrade an old file, that mess is sorted out, normalized, and copied to the correct object.
To maintain the old format would require remixing everything back together only to sort it out again next time it’s loaded.
But, more importantly as I continue to add features/settings to the new binding system some of those settings won’t have a place in the old file format to store them - so I need a new format for that anyway.
So basically I needed a new format to support the new bindings, but I also need to upgrade the old system because if everyone had to re-create their bindings from scratch I wouldn’t be very popular 
Make sense?
Yes, makes sense. Thanks for the response. Bindings…
Just tried evaluating new 4100+ build (took the latest one) and unfortunately I see some regression in relative encoder mode support. Unless I’m missing something bidirectional relative encoders bindings are not supported with the new system. Also, mapping curve parameters now are not available for relative encoder bindings.
For example, here’s binding that works with old system:
Here’s what I get with the new system:
The error message in red says the reverse mapping is not supported and indeed the binding doesn’t work until checkbox on “Bi-directional” is removed.
@brad, please bring this feature back 
PS. Anticipating questions of sort “What MIDI controller are you using and why do you need that” - I’m using infamous X-Touch Mini controller with encoders configured in “2’s complement”. Turns out (can elaborate if needed) relative mode is the only “workable” mode for this controller (and I assume the same for entire X-touch family, may be BCF2000 too).
I’m on it… (this was an oversight, not deliberate)
