Windows 10 64 bit, running Cantabile build 3.0.3570.
Song has 4 media players (playing 4 minute long MP3s), first media player is master, others are real-time slaves.
The tracks were recorded a bit slower than they should have been, so I’m using the speed setting on all 4 media players to play at 102%. When I try to switch to a different song after this song plays to completion, Cantabile becomes non-responsive and has to be restarted.
I’ve worked around the issue by using bindings to adjust the speed to 102% on transport play and 100% on transport stop.
Edit: Interesting side note, I’ve got the exact same situation on another song (4 media players playing MP3s), where the speed is saved at 97% and it works with no issue at all.
I’ll need to reproduce this to sort it out. Can you try setting up a simple song with just and the four media files that reproduce the problem and send it to me?
Hey @Brad, so interesting news on this front.
On my PC at home, the problem doesn’t occur. It’s also a Windows 10 64 bit machine running build 3570, playing the exact same song file and using the exact same MP3s (data from cloud drive). I don’t know if it’s machine specific or has something to do with modifying the song file and saving it again. I will look into this more and get back to you if it’s still an issue.
I’m guessing it was just a weird one-off because no one else on the forum chimed in.
On my band laptop, the problem was still occurring, making the issue seem machine specific. I put the bindings back in to reset the speed on transport stop, but this time the problem did not go away. I removed the bindings and saved the song with the speed set to 102%.
While troubleshooting I noticed that even though the song had played completely, Cantabile was indicating that the transport was still playing. All 4 MP3s have a few seconds of whitespace at the end, so I created a new transport position binding a second before the end of the song that stops the transport. Since doing that Cantabile hasn’t become non-responsive a single time, regardless of media player speed.
In the interest of troubleshooting even farther, I loaded Cantabile on my work PC to try it there too. It also becomes non-responsive when playing this particular song, but the binding to stop the transport before the end of the song fixes it as well.
I can zip up the files to the song so you can see the issue if you want, but there’s a 33% chance that the problem won’t even occur for you…
The only thing I can think of that might be machine dependant and might effect this is the audio buffer size and sample rate. Are they different on the machines that cause trouble?
The two PCs that hung up were at 44.1k, and the one that wasn’t locking up was at 48k. When I switched the one that doesn’t hang up to 44.1k, it hung up as well. The binding to stop the transport manually fixes the issue on this PC as well.
Since I don’t have issues with the other Cantabile songs that are almost identical to this one, I would think the issue would be with the MP3 files, but they haven’t changed since they were created February of last year.
I’ve been looking at this but thus far haven’t been able to reproduce it. Can you try removing the rack you’ve got attached to each media player and let me know if that makes a difference (I had to do this as I don’t have some of the plugin’s you’re using). ie: trying to reduce this to the simplest possible case before debugging it.
Also, when exactly does this happen? I’ve tried switching to another song while it’s playing, I’ve tried going File New while it’s playing. I’ve tried switching songs after it’s finished playing. I’ve tried these tests at 44.1khz and 48khz. No issues so far.
Hi Brad. To summarize the issue: The transport is not stopping automatically at the end of the media files.
Per your instructions I did the following:
Created a new empty song
Added 4 media players
Removed the stereo output and midi output on all 4 media players
Added a mono output port to all 4 media players
Added the corresponding files to the media players
Set the playback speed to 102%
Attached the media players to the mono output ports
Set the “click track” media player as master, the others as real-time slaves
Made sure sample rate was set to 44.1khz
Played song, let run uninterrupted until the end of the files
Found the transport service still in “play” mode
Tried to switch songs and could not (app hung)
I then tried again with just the file named “Hold The Line - Click Track”:
Created a new empty song
Added 1 media player
Removed the stereo output and midi output on it
Added a mono output port
Added the “Hold The Line - Click Track” file to the media player playlist
Attached the media player to the mono output port “Click Track”
Set the playback speed to 102%
Set the media player as the master
Played song, let run uninterrupted until the end of the file
Found the transport service still in “play” mode
Tried to switch songs and could not (app hung)
I’ve attached a screenshot of what Cantabile looks like before I try to switch to a different song:
Since my last post, I’ve also tried creating a new song with a single track, but did not change the speed to 102%. Cantabile did not hang when it finished playing.
I used an MP3 from another song, added the same way as before including setting the speed to 102%. Cantabile did not hang when finished playing.
Opened the “Hold The Line - Click Track.mp3” file in Audacity, exported it again using the newest version of LAME_encoder.dll. Tried playing the original song with speed set to 102% without the binding to stop the transport. Cantabile did NOT hang.
Opened song, removed the binding to stop the transport service, saved the song. Closed Cantabile. Re-opened Cantabile, played song, Cantabile did NOT hang.
I’m not sure why this started being a problem with this particular file (that had been unchanged since February of 2018), or why it seems like it was such a specific set of circumstances (speed set to 102%, sample rate set to 44.1 kHz), but it seems re-exporting the file in Audacity has fixed the issue.
This problem started either 2 or 3 weeks ago ( I want to say the first time it happened was after upgrading to build 3564, if that means anything), but I didn’t realize it was specifically this song until a few days ago.
Sorry for wasting your time @Brad, I thought for sure this was some kind of weird bug.
Hi, this may be a dumb observation, but would it not be better to fix the root cause of the issue (the files) by re-sampling outside of Cantabile using a tool like Wavelab or similar to fix the speed issue. It’s a one time job then, and you are not putting unnecessary real time load on Cantabile.
I want to keep my real time sample buffer for what needs computing live, and offload anything that does not need to be computed live, if you see what I mean.
Just a thought
It’s fantastic if Brad can fix it of course, for the times that you really need it…
The root cause of the issue as determined by Brad was something to do with the media players in Cantabile, not the audio files themselves. You raise an interesting question though; does having Cantabile adjust the playback speed make an appreciable load difference?
From what I can determine with the system profiler, it looks like the answer is no. I’d say the difference in load is right around .05% for each media player when you compare a song at normal speed vs. one sped up or slowed down.
That shows the power of the new profiler . With that % difference, then having Cantabile correct the speed is not going to make the processor break out in a sweat, unless you are already living on the edge, which is not a good place to be!
Possibly, but if there are issues in Cantabile I need to fix them.
Just to be clear about this. Time/Pitch shifting audio files does have an impact on CPU load - however it might not show up in the profiler. The profiler only profiles Cantabile’s real-time audio threads. Audio resampling, time and pitch shifting all take place on background worker threads. So they will impact CPU, but not necessarily show up on the profiler - unless you look at “CPU load” not “Time load”.
