Hi Sergio,
As far as I know when Version 4 first installs it copies the settings file from the version 3 folder to the newly made version 4 folder. At that point the 2 settings files in the V4 and V3 folders are different and if you make changes to one they will not be automatically copied to the other one. You could try copying the settings file manually from one version’s folder to the other but make backups in case it creates issues, it shouldn’t.
Dave
Dave, from what I understand, an integral translation from C3 to C4 only occurs with the first installation. But some data remains stored somewhere on computers. Where is it? I think that once these data are found and deleted, everything is translated “from scratch”. I think Brad, in particular, knows where to look for this data !!
However, the fact remains that to copy the buttons created below I modify or increase them, but when I go to C4 they are not there !!
I was wondering if this series of buttons could be copied from C3 and pasted into C4, because doing them again takes too long!
Sergio
Hi Sergio,
It is located in the Users folder that you use in the C:\Users\User Name\AppData\Local\Topten Software. It will have separate folders for the 2 versions and in each one there will be a settings file.
I understand, What I suggest is that you
I hope this makes sense & it does work.
Dave
All right. To do this I had to keep the two folders open, because C3 and C4 cannot be opened together. I made the copy and everything is fine. The controller bar is identical for both Cantabile.
Thanks for the tip, Dave
Sergio
Right now the settings folders are compatible between v3 and v4 but this probably won’t be the case indefinitely (though almost certainly until at least v4 is stable).
So you can either:
Cantabile 3.0 (x64) and rename it to Cantabile 4.0 (x64) (or vice versa to go the other way).Cantabile 4.0 (x64) folder and Cantabile 4 will re-copy from v3 settings.Hi everyone, hi @brad.
I created bindings for some rack states (up-down associated with CC controlled by external midi controller) with C3 and they work fine.
I saved in C3 and ran C4 to test them, but they don’t work. Can this be my problem or a bug?
Regards
Sergio
I found another minor detail with the show/hide pop-up feature: If I use F4 to hide all the pop-ups, then they do not show if I use a binding to trigger the Show GUI Editor. If I use ESC key to close the GUI editor instead of F4 then the binding works well.
Sounds like a bug - can you post a screen shot of exactly how you have the binding configured so I can investigate.
Interesting - I’ll check it out. Fixed for 4020
Brad
Hi Sergio,
I notice in the screenshot that in the Routing table, the Main Keyboard is greyed out. I can’t recall what conditions will cause the Source to be grey, but I suspect that might be the issue why the bindings aren’t working.
Cheers - David
Well, it happens, for instance, when the destination plugin is unloaded (or a destination rack is suspended).
Gabriel
Hi, David. As soon as I get home, I check your suggestion.
In the previous post I explained that I had prepared the states in C3 and that everything worked fine. C4 should keep everything you save in C3.
At least that’s how it should be. Maybe something might not be saved in C4 as well.
In fact I had reported a similar case where the bar controller was not being maintained by C3 in C4: Brad had answered for this, recommending a shortcut.
Also consider that C4 is constantly evolving, so something can escape !!
Thank you for your recommendation.
Sergio
David, sorry.
Gabriel pointed out to me that the Memphis Main keyboard rack was suspended.
Actually the rack states that interested me were for the rack organ, which was active (you can hardly see it).
Memphis you see it, but I had added it later for another try, and I muted it to not affect the rack organ and rack states.
Hi @Sergio,
I’ve had a look at this and tried to duplicate your setup for testing and I think I might know what’s going on. In your rack you have two bindings for each of the two CCs 109 and 110. The first pair move to next/previous song state, the second pair move to the next/previous rack state.
This is a conflict since only one delay load action can be active at a time.
Basically what will happen is the first binding will be invoked and start a delay load operation, then the second binding will be invoked, cancelling the delay load operation of the first binding.
I haven’t been able to see any difference in behaviour between v3 and v4 however this can be affected by these options in Options → Keyboard and Controls:
If “wrap around at end of rack state list” is enabled, then the second set of bindings will always take effect because they’re after the first set and will cancel the song state delay load and take over.
If “wrap around at end of rack state list” is disabled, then if the current state is at the start/end of the list and there’s no where to move to, the second binding won’t start a delay load operation and the song state delay load will remain active.
That’s all a bit convoluted but it’s caused by having the two conflicting bindings.
Brad
Hi Brad
I left the second settings off and it would seem that these are the ones that generate the conflict. So do I have to cancel them entirely? The EC5 I use it only when I use the pedal, so either I leave the one in bar control or the EC5, right ?. In C3 they are the same settings, but they work fine. I’ll try to create another binding all over again directly in C4 and then I’ll let you know.
Sergio
hi @Brad.
I think I’ve solved the problem.
I set up a new rack for the up-down states rack test.
Now everything works in C4 as well.
I deleted CC109 and 110 and reassigned up as CC116, down as 117, first as 118 and last as 119.
I also left my EC5 (my midi controller) set, for testing not on screen, but physically, with the pedalboard.
The reason is surely to be found, (my fault) on some repetition of binding where there were CC109 and 110. I have to reopen my rack and search for the error.
But the fact remains that, keeping that rack in C3, everything works fine.
I send 2 screenshots, “clean of everything” with only the part concerning my question.
A clarification: with my bar controller I do my tests, before using my EC5 midi controller. As you can see there are only buttons!
Regards
Sergio
@Brad, sorry again.
What happens is this. I’ll preface this by saying that I use C4 in English, but for convenience, I sometimes use my own language to understand some translations and then switch back to English.
As I said, the up-down per rack in C3 worked, but in C4 it did not.
Then, thinking about my mistake, I prepared a new rack (the one I sent you) and everything went well.
I started reviewing some things again in both C3 and C4 and the problem resurfaced.
I started to see the various differences and I think I figured out what happened.
I realized this:
Remember how I couldn’t see the controller bar created in C3 on C4?
At your suggestion (@dave_dore and yours) I copied the setting.json file from C3 to C4.
It happens that if I copy the setting.json from C3 (while I’m using the Italian language) to C4 I must have the Italian language positioned in C4.
In fact I verified this and everything works perfectly.
I don’t know if this could be a bug: maybe the setting.json contains some formatting in Italian, so when I copy this file in C4 some things are not interpreted correctly by C4. This is my guess, but of course I rely on your unquestionable judgment!!!
Sergio
And one more for the show/hide GUIs: I have a rack with a few states, and I have made a cloned copy of each state to use for setting up the state, i.e. opening for a lot of bindings to fiddle with settings - and showing the GUIs, so I can see what I am doing. I have marked the Editor Visibility to be state dependent, and I have excluded it from linked clones:
Now I try to hide the GUI in the normal state, by using escape key to close it. And in the setup state I open the GUI by double clicking the plugin. Both actions works fine, but unfortunately also affect the linked clone, so the GUI keeps it visibility (on/off) from the linked state.
Am I the only one who sometimes looks at the GUIs - can’t see anyone else reporting issues in this area 
?
Addendum, just tested in C3, same issue/behaviour. Maybe it is me doing something wrong?!? I expected that the GUI visibility was handled by opening by double clicking the plugin, and closing by pressing ESC key. And this would be the ‘known’ visibility that would be registered with a state, assuming that the “Editor Visibility” is ticked. Thus, if creating a linked clone, and selecting the “Exclude from Linked Clones”, then I assumed that this would mean that the linked states would handle the GUI visibility independent of each other.
Hi @TorstenH and @Brad and other fellow ‘Cantabilians’: The issue I have relates to racks but also to some individual VSTs. It is not a bug I think, but intentional behaviour
In the indicator on the main song/routing overview displays the volume of the rack/VST, which is nice. Recently I guess this was changed: if a rack or VST has more than 1 stereo out or L+R pair (typically 16 or so), the indicator bar changes to display them all 16 (right?). For many, I basically only use 1-2: the stereo pair or mono output. In this way, I hardly see anythng on the volume of those particular racks or VSTs (the volume bars are too small for me at least to see clearly), which I find a pity. I guess my evaluation is right. If it is, then this request is more a feature request to have the volume indicator choose to display only the mono or stereo ouptut volume of tracks 1 and 2, or generic x and y out of 16 or more, as a user option in the GUI. If I am wrong, or if this is already possible but I have not found it, please enlighten me.
Thanks great guys (and girls?)
Ad
p.s. immediately after writing this, I went checking in the latest 4.24 version, and I cannot actually reproduce the volume indicator issue anymore, so it already seems changed recently?. If so, the request is already taken care off, so thanks!
@Brad, I am working with your latest v4 issue. I can’t judge performance differences very clearly and help out there. VST4 seems to work fine. Have some crashes when I switch too fast in racks of big sample libraries (e.g. East West Play) between sample/RAM-thirsty states. I need PLAY to take its time to load them (I have ultra fast SSD’s so loading time no issue for me luckily), to avoid crashes of Cantabile, but after full load of the state, there is no issue anymore.
I just had a crash on using the East West Play Rack with 4.24, upon changing states, but while feeding new notes (the new notes may also be the bottleneck). Sent in a crash report just now.
Maybe there is a way to have Cantbalie not crashing on those situations, but it is not a big deal for me, I can avoid it.
Ad
By the way you have a done great work again @Brad with V4. I know it can be not very rewarding changing the (for users hidden) architecture and language of the code, especially if functionality does not change drastically for the users (I know since I lead a scientific model development team). So users might not understand/reward the changes at first vision. But I guess they’ll realise when you can build changes in future versions of 4, that you could not have done with v3. So a big thanks
