2 Bugs: Inescapable start/stop loop & Unstoppable Playba

[Industro]

Bug Reports:

Using Metro 6.3.2.4:

When in the Graphic Editor of a multi-track audio project, the following key stroke combination causes Metro to lock itself into an endless inescapable play/stop loop, causing 100% processor usage and no way to stop it, unless you force quit:

Briefly click and hold the space bar while click-dragging the cursor in an audio track of the Graphic Editor. This will cause the program to stop responding.

While this key stroke combination isn't common practice in Metro, it IS commonly used in Graphic Editing software (like Adobe Illustrator) to scroll about the canvas (holding down the space bar activates the "hand" tool so you can scroll freely by click-dragging the mouse). Because I frequently go back and fourth between the two programs, I often find myself locking up Metro. This bug is 100% repeatable on my system.

Bug Report #2

Clicking the "Record" button in the transport without an audio track enabled causes the usual "Recording is not enabled" error message to appear. However, immediately following, playback resumes and cannot be stopped via the stop button or space bar. In fact, there is no "visual indication" that anything is playing, except for the sound. Pressing the "Play" button in he transport is the only way I know how to stop it.

Hope this helps.

Thanks for keeping Metro at the top of its game!

[Jerm]

Briefly click and hold the space bar while click-dragging the cursor in an audio track of the Graphic Editor. This will cause the program to stop responding.

Perhaps I am not doing this right but when I do it, Metro will start and stop playback a bunch of times as soon as I let go of the mouse. This is because the spacebar has been buffered. It does not lock up the machine for me but perhaps you are taxing your CPU more with the sequence you are using or you have a slower CPU. What happens? Does it start and stop playback?

Clicking the "Record" button in the transport without an audio track enabled causes the usual "Recording is not enabled" error message to appear.

I cannot repeat this either. Perhaps you could give more info on the document that is causing this or if you can repeat it with a small(ish) document you could email the Metro .bndl file to me.

Thanks.

[Scoot]

Using Metro 6.324 G4

Hopefully I've got these right..........


The way I read error 1 and reproduced it is you're starting and stopping the track from playing. The longer you hold the space bar down before the drag, the longer it will do it....cause in Metro the space bar can be used to begin play or stop it.
It does not go on endlessly.
It goes on until it has played and stopped as long as the space bar has been held down. While you're dragging you're building up the amount of times it can do it.
Without the drag, it behaves more like a staggering play and stop along the track.
With the drag it 'hammers' a small sample area on and off....possibly for a long time.

I wouldn't think it's a metro bug.
Is it more of a OS timing/execute operation thing?
I couldn't see a fix. ??? We want space to be start and stop.


Error 2 -
no record track selected
click PLAY then RECORD
dialog comes up warning no recording track....ok it
music plays - registering signal in the mixer's meters but no counter movements in the transport window.
Can be stopped with the play or rewind button but not stop button or space.

Sort of a bug?

temp/final fix?

Workaround - change the recording method
without selecting a record track
hit record (not play) and you get the warning as above, clear it and nothing else happens.

select a recording track
hit record and everything works fine.

My question is why hit play and then record? That's what I believe is causing the problem.
It is not neccessary............and you could miss the beginning or something.
Just hit RECORD.

[Jerm]

Error 2 - no record track selected click PLAY then RECORD

Okay. I missed that. Play is pressed first. This is a bug and will be fixed in the next pre-release.

My question is why hit play and then record?

This is called "on the fly" recording and allows an engineer to punch in at a specific time.

[Industro]

Bug 1:

With the drag it 'hammers' a small sample area on and off...possibly for a long time.

Yes... this seems to lock up Metro indefinitely on my machine (1.25 Powerbook G4, 1 GB RAM) while it hammers the selected sample. I get the "spinning beach ball" between every 3-4 attempts at playback, which lasts about 15 seconds each. I never waited more than 5 minutes to see if the problem would stop on its own, I just Force-Quit. It doesn't seem like I held the space bar down that long to build up such a large buffered list of commands, but that "feels" like what has happened. Metro tries to start and stop playback, over and over, until it has completed all the requests... but they just keep coming.

I'll try to isolate any other variables that I may have overlooked when it happens again, and I'll report on my findings. Hmmm... maybe it only does it with "fresh" newly recored audio (prior to a Save)??? That seems to be when I notice it...

Bug 2:

Can be stopped with the play or rewind button but not stop button or space.

Yup. That's the issue. Not too serious, but I got really flustered when I couldn't get playback to stop by pressing "space" or "stop" in the Transport.

Thanks for looking into this guys.

[Jerm]

Hmmm... maybe it only does it with "fresh" newly recored audio (prior to a Save)??? That seems to be when I notice it...

I don't think it is related to freshly recorded audio. What OS are you running? Maybe your disk buffer size set in preferences is too high. Each playback will pre-fetch each tracks audio buffers so if you have a lot of tracks this may take some time. How many audio tracks do you have?

The audio file for the newly recorded data will remain on your hard drive if you force quit and can be recovered by finding it and dragging it to the graphic editor (or importing it).

[Industro]

I'm using 10.4.3, 1 GB RAM, Playback Buffer is set to 256 thousand (k) bytes.

I have a lot of audio tracks, about 24, some are stereo, so that equates to even more. I have no other playback problems though.

Now, I'm having trouble getting this problem to repeat (after having no problem doing so before). I can get playback to stutter a few cycles, but now it resolves after a few seconds.

There must be another factor involved that causes this. Next time I experience it, I'll try to be more methodic in my troubleshooting to determine the proper culprit.

I'll let you know if/when I discover something.

Is there a process log or something in the OS that can display what is happening (during the playback problem) that would be beneficial to you? I know the Activity Monitor shows 100% processor usage by Metro during the hiccup, but is there a way I can provide you with some other info that would be helpful?

[Jerm]

Is there a process log or something in the OS that can display what is happening (during the playback problem) that would be beneficial to you? I know the Activity Monitor shows 100% processor usage by Metro during the hiccup, but is there a way I can provide you with some other info that would be helpful?

There are some programs that can tell what is happening when a program is locked up, such as thread viewer, but with a release or pre-release version of Metro (non debug-build) the information provided will be virtually useless.