Cantabile 4 Alpha Available

[TorstenH]

Hi, will just tell you that latest version is 4.24, so you are a couple of releases behind.

[adderoo]

Hi @TorstenH, my fault, thanks for noticing. I am using version 4.24, but wrote incorrectly 4.14. Will correct in my posts (done). Also did come across East West PLAY rack crash just now, still in 4.24

[brad]

@TorstenH

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.

I just did some testing on this and it seems to be working fine. Can you send me a reproducible case?

@adderoo

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!

Yes there was an issue here which was fixed at some point in the v4 alpha.

@adderoo

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.

Hard to say - if it’s the plugin itself crashing Cantabile doesn’t do anything to suppress those crashes (deliberately, since masking issues just makes them harder to find). I’ll check out the crash report during the week and see what’s going on. Just had a look at the crash report, it’s definitely crashing in the plugin during audio processing. I’d say this is a bug in the plugin.

[TorstenH]

Regarding the GUI visibility testing

@brad

I just did some testing on this and it seems to be working fine. Can you send me a reproducible case?

I assume I am doing something wrong, so I will give the steps to reproduce:

1. Create a new empty song
2. Add a plug-in, I used Pianoteq
3. Create a state, name it Play (to be used without GUI visible)
4. Create a linked clone of that state, name it Setup (to be used with the GUI visible)
5. Select the Pianoteq plugin and in the “State Behavior - Puging” tick the Editor Visibility check box plus right click the check box and make sure that “Exclude from Linked Clones” is marked.
6. Select the Play state, and if the Pianoteq editor is visible then click Esc to hide it.
7. Select the Setup state, and if the Pianoteq editor is hidden double click the plugin to show it.
8. Now select the Play state again.

In my test the editor is now shown in the Play state, which confuses me.

Testet in 4.24, completely fresh install. I attached the song I created.
GUI display issue.cantabileSong (27.3 KB)

[brad]

@TorstenH

I assume I am doing something wrong,

Nope, it was a bug related specifically to that one behaviour “Editor Visibility”. It’ll be fixed in 4025.

Brad

[Torsten]

Just did a bit of performance testing with the latest version (4025) on my studio rig - and things are looking pretty good here:

• my Perftest song (5 instances of TyrellN6 blasting away) runs at an average of around 32% time load with maximum around 38% with C4

• the same song in C3 runs at a 33% average with maximum around 40%

Both with Null Audio Engine at 128 samples.

Haven’t tried it on my heavier live songs yet, but will install on my Live Cube over the weekend and give it a real shakedown…

Cheers,

Torsten

[brad]

Great… thanks @Torsten

[Christoph]

Hi Brad, in our last rehearsal i played around with cantabile 4. I play in a Marillion Tribute Band and I have some complex rigs. All Instruments worked fine. There was no problem with CPU or latency. The only thing that happened that the usb connection to my oxygen 49 got lost two times in about 3 hours.
As Vsts I use native Komplete, the Arturia V Collection, Omnisphere and the Juno 106 Emulation from cherry Audio

[dbrendon]

Hi @brad,
I noticed a ‘cosmetic’ issue - perhaps it’s intentional.
When a binding is disabled, but has a filter applied, the filter is ‘lit’ instead of grey.

Cheers - David

[TorstenH]

A very minor slightly cosmetic thing: when renumbering a few selected states in a rack, the order is changed. I tried to go from this:

and selected to renumber, starting from 15, and I got this:

and I expected this:

i.e. that the renumbering preserved the order of the states.

[brad]

@dbrendon

When a binding is disabled, but has a filter applied, the filter is ‘lit’ instead of grey.

Thanks for reporting. It’s not really intentional, nor a bug but I can probably improve it. Leave it with me. Fixed for the next build.

@TorstenH

A very minor slightly cosmetic thing: when renumbering a few selected states in a rack, the order is changed

Thanks for reporting. Fixed for the next build.

[TorstenH]

Great. An even smaller minor detail, in the Edit Midi Ports window, if I press Alt-A as a shortcut for Add, then the Add button is selected, but I need to press Enter to open the drop down. I am pretty sure that in C3 the drop down was opened (but I haven’t checked).

[brad]

@TorstenH

but I need to press Enter to open the drop down

I’ll fix it…

[dbrendon]

@brad, I think I may have found a bug in 4026. I am unable to [Add] an External tool. All buttons are greyed out. Can anyone else confirm?

[TorstenH]

Works fine for me. Have you tried entering text in the fields?!?

[dbrendon]

Yes. All fields are disabled. It works fine for me with C3.
Now, I just tried External Tools on my desktop machine and I have the same issue with C4, but it also works fine for C3.

[brad]

@dbrendon

I think I may have found a bug in 4026. I am unable to [Add] an External tool. All buttons are greyed out.

Thanks for reporting. It’s a bug when there’s nothing in the list. Fixed for the next build.

[Tweaker]

Hi @brad,

Found a possible bug in v4 while working with @dave_dore’s new B-3X Factory rack. When clicking Custom Button 2 to create a new state the GUI Editor takes the foreground in v4027 but doing the same in v3701 the GUI Editor is placed in the background.

https://community.cantabilesoftware.com/uploads/short-url/gw6iX3DiIAnvgZvEZMH0Pu5Lq0S.zip

[dave_dore]

Hi Al,

This isn’t a bug, the timing of the display items when opening many things at the same time is not always the same. It is a part of the way tasks are done in C3. I am going to see if I can improve this using the new delays features Brad just released. I’ll let you know if I can improve this part after I get the hang of using the new feature, I’m sure I can, the flexibilty and precision is definitely there I just need to get familiar with it. But it will be for Cantabile 4 only.

Thanks,

Dave

[Thijon]

I found a reliable and reproducible way to crash Cantabile 4 on my system. So far I’ve only noticed this for a specific song. I will try to reproduce this with a new song.

The Song has a few linked states (like Verse 1, Chorus 1, Verse 2, Chorus 2,…). When I switch between states normally, it works just fine. However, when I switch to live mode (which also switches the view to note view) and load the next state (i.e. Chorus 1) via a MIDI binding, Cantabile crashes. I tried remove all racks and plugins successively and the error persists even if the song consists only of those linked song states (no racks, plugins, bindings, notes).

I’ve looked through the log files and the exception causing all of these crashes is this one:

00030419     3244   [13344:2]: State loading 'Chorus 1' for '012 Cry for You test'
00030419        0   [13344:2]:   Starting route operation: loading state
00030420        1   [13344:2]:     Nested route operation: enabling route
00030480       60   [13344:2]:   Finished committing re-route: +10=86, 60ms
00030493       13 ! [13344:0]:   Exception
System.NullReferenceException: Object reference not set to an instance of an object.
   at #=z_eiTETclZPdN8kJrfv$_YkY=.#=z_3MVLrY=.#=zzqarF8LKzkEO(Boolean #=zpWVXrbdJvryl)
   at #=z_eiTETclZPdN8kJrfv$_YkY=.#=zypRNpOHUQG$E()
   at #=z_eiTETclZPdN8kJrfv$_YkY=.#=zhcvEUuwrwMNy(#=z3vUjCF9At6cxpv1WDME8fF_EZIRy #=zCRjUXdg=)
   at #=z3DsZ$6mc6sg5HEWbB6cFJ94QHoI9sko$Dw==.#=zTUXYunV71qw9(#=z3vUjCF9At6cxpv1WDME8fF_EZIRy #=zcMP2zHY=, #=zxTlFO3wNt6uckfIcAY$$otUBMjPTyBLK8A== #=zpxevcK0=)
   at #=z3DsZ$6mc6sg5HEWbB6cFJ94QHoI9sko$Dw==.#=z1uDihjv44VhRDz47vRKpv3Y=.#=zXWoV6h$SjeJW2LbX0w==()
   at #=zvvrZhv$mUDhTaYcmBKJy83I=.#=zSg_VIOrbneAmdLjMDfKq$gI=.#=zyAOIqojeQT4R$xBSHIiZ0sI=()
   at #=zw0r96JkvhWgpZcu4Jn$lAp7DOdNJw00jJw==.#=zUbGSh0kVKTPg()
   at #=zrUVWfdzVkeJxA6KE5gRiBM4=.#=zJzAO2xWPi9_VwvNrbw==.#=z7vZ2h4AjjuFDj5CPXA==()
   at Topten.GuiKit.PostedCallback.<>c.<.cctor>b__2_0(Timer t)
   at Topten.GuiKit.Timer.on_TimerTick()
00030493        0 ! [13344:0]:   Launching crash reporter...

At this point I really hope this is a bug and not faulty memory as the stack trace looks really wild.

EDIT 1: Just tried building an empty song. It really seems to be somehow connected to linked states. When I create the same song states as above, switch to live mode, switch to the next song state, it crashes. If the song states are not linked, it seems to work fine. However, if I then create a new linked clone, it crashes immediately.

EDIT 2: When I unlink the states in that first song, it seems to work as well.

EDIT 3: I did some more testing to rule out that notes view or the MIDI binding are causing the problem. I can crash C4 consistently as long as I’m in live mode and switch to a linked state.