The Multiproject Wormcan
- 1 Top Level Options
- 2 Gale 17Mar16
- 3 Comment from Steve
- 4 Peter's worms for the worm-can
- 5 A wormcan issue reported by Gale on on the Forum - transferred here
- 6 Warnings about skips
Top Level Options
Three of our options include:
- Each project can play/record independently. If several are playing we mix.
- Single recorder/player model. Many details to work out, such as whether to disable other projects whilst playing or for acting in them to stop playback.
- Mono-project. Completely disable multi-project (yes it's a regression, but if we are currently very buggy and e.g. mix up aup files it may be worth it).
Comment from Peter 17Mar16
I strongly support option 2 above "Single recorder/player model". This is the approach for Timer Record that Vaughan adopted when he originally implemented that functionality, locking all open projects other than the Timer Record one in order to protect the safety and integrity of the scheduled or active timed recording.
When Mark Young upgraded Timer Record he effectively made it a "solo-project" - you get an error message if you try to set up a Timer Record with other projects open and you must close those before proceeding. This is done to protect against "dirty" projects remaining open in the event of the new optional Audacity Exit or optional computer shutdown. But it should also give us the great advantage that we can make the Timer Record modeless and thus we should be able to grant access to the controls.
When any particular open project is playing or recording then all other projects should ideally be locked (the Stop/Pause/Play/Record buttons in other projects are locked and unavailable, as are the Mixer toolbar sliders).
If exports and effects were on a different thread, as aliased PCM imports are, it could be much safer to work in other projects while running effects or exporting.
Comment from Steve
Steve commented to me offlist:
"Personally I've rarely used multiple projects. It's always been a bit iffy, and most uses of multiple projects can be performed as easily and more reliably in a single project. However, for users on powerful multi-processor machines, I see the obvious attraction of working on one project while another project is processing or exporting one or more long tracks."
Peter's worms for the worm-can
I actually started testing multi-projects (single user) today (5Jan15) - all my multi-project tests are being done on Audacity reset with both .cfg files deleted:
Recording in Project-1, then in Project-2 using the Transport toolbar (Play or Record buttons) can stop the recording in Project-1 (logged as bug #814 on Bugzilla)
- Peter 22Dec16: This has been fixed with the resolution of bug no. 814
Playing in Project-1, then in Project-2 press Play button. This will stop the playback in Project-1
- Peter 22Dec16: This no longer appears to be the case in the latest 2.1.3 alpha 15Dec16. When playing in project-1 the play button (and other transport buttons: record, pause and stop) are grayed out and inoperable in project-2
Recording in Project-1, then in Project-2 press Ctrl+click in the waveform and try to drag for Scrubbing. This cannot be done so the attempt to initiate scrubbing in Project-2 is correctly prevented from interrupting the recording in Project-1
- Peter 22Dec16: This no longer appears to be the case in the latest 2.1.3 alpha 15Dec16. When playing in project-1 scrubbing/seeking is unavailable and inoperable in project-2
Recording in Project-1 - Timeline is now disabled in both projects which means that you cannot invoke Timeline Quick Play in Project-2 and thus thatcannot impact on/stop the ongoing recording in Project-1.
- Peter 22Dec16: This is not a MP-worm - this is as it should be.
4) Changing items in the Device Toolbar in Project-1 makes the same changes in Project-2 (but I kind of expected this)
5) In multi-projects the the Mixer Toolbar record sliders are all ganged together - same true for the playback sliders
6) The Tools Toolbar appears to operate independently in each project in multi-project working
7) The Meters Toolbars appear to operate independently in each project in multi-project working. What is saved on exit is the setting of the last project exited from.
8) The Edit Toolbar appears to operate independently in each project in multi-project working
9) Preferences appear to operate independently in each project in multi-project working.
10) Snap To appears to operate independently in each project in multi-project working. What is saved on exit is the setting of the last project exited from.
11) Selection Tools appear to operate independently in each project in multi-project working.
12) If recording in Project-1 then recording in Project-2 is inhibited.
Play will only play in one project, but shifts to project with the latest press of Play key.
14) While recording in Project-1, effects, generators and analyzers can operate in Project-2
- 14.1) But Undo/Redo tools in Project-2 doesn't work - but Edit>Undo and Edit>Redo do work.
15) When Playing or Recording in Project-1 you can't used File>New or Ctll+N to start a new project - but you can invoke one by clicking on Audacity.exe
16) When Playing or Recording in Project-1 you can Save and Export successfully in Project-2
17) When Playing or Recording in Project-1, then go to Project-2 and use File>Exit or Ctrl+Q - these will stop and close both Project-2 and Project-1. 17.1) However if you use to top-right red X to close Project-2, Project-1 carries merrily along uninterrupted.
18) Timer Record
- Peter 22Dec16: Done for 2.1.3
All activities in other projects are disabled when Timer Record is active or just waiting-to-activate in one project
Start recording in Project-1, you can then initiate a Timer Record in Project-2 - TR starts on cue in Project-2 but doesn't record. You then can't do anything in Project-1, but it does carry on merrily recording. The TR continues until it reaches its scheduled stop time whereupon it stops with an empty recording/project AND the ongoing recording in Project-s is summarily halted at the same time.
Then if you Stop the TR or when it finishes on cue not only does the TR "stop" - but it also stops the recording in Project-1.
When a Timer Recording stops (or is interrupted) in Project-1, the Quick-Play in Project-2 is disabled (this is likely to be part of bug #813
19) When items in the Transport Menu are changed in Project-1 (Overdub, Software Playthrough) - then the same changes also occur in Project-2
20) when running two open projects, save Project-1 as "Project-1" then try to save Project-2 with the name "Project-1", Audacity will safely not allow thisand gives an error message.
Set Project-1 to monitor input, then press Play or Record in Project-2 results in monitoring in Project-1 is stopped in favor of the activity in Project-2
- Peter 22Dec16: This no longer appears to be the case in the latest 2.1.3 alpha 15Dec16. When Monitoring (or playing/recording) in project-1 the Device Toolbar is grayed out and inoperable in project-2
21.1) but worse than that Project-2's Device Toolbar is grayed out and remains grayed out, even after Project-1 stops playing or recording.
Bug no. 1366: Using the sliders in Mixer Toolbar in a Project-2 alters levels in on-going recording (or playback) in Project-1
- Peter 30Nov20: Fixed by Leland a while back
Which of those worms concern me
No. 22 Bug no. 1366: Using the sliders in Mixer Toolbar in a Project-2 alters levels in on-going recording (or playback) in Project-1. This one concerns me a lot
- 15 and 17 seem odd and inconsistent
- 21.1 looks like a bug
Multi-recording with two users
Preliminary tests that I have been doing for Leland recently indicate that, on Windows 7 at least, you can get Audacity not only to play elsewhere but also to record elsewhere, an entirely separate recording.
But to do that you have to leave Audacity running, recording and then "Switch User" to a second logged-on user and then start playing or recording there.
I managed to get User-1 recording form my external USB card and at the same time User-2 recording WASAPI loopback (and actually recording the iTunes that was playing on User-1) without seemingly getting any audio paths confused and both recordings being fine - I was *not* expecting this outcome.
- Gale 27Mar16: This may be problematic on Windows 8 and 10 in so far that "commonly" the audio engine is suspended in the account that is not active.
Multi-recording with two instances of Audacity
This can be achieved by using current Audacity on different computers or current Audacity on one computer together with an early enough version of Audacity such as 1.0.0 that does not respect lock. I have recorded two physical sources safely several times using HEAD and 1.0.0 on Windows 7.
How unsafe are multiple instances of Audacity on the same computer in reality? Is it just an issue of raising our system requirements? Mono-project would be less painful if we allowed multiple instances.
I don't think we should ever recommend using long-time obsolete and unsupported software (see: risks). If we really want to suggest recording in one application and editing audio in another, then it would be much better to suggest using up to date and supported software. However, even then there are very significant risks of losing work.
- Gale 27Mar16: On other than Windows we don't have to recommend obsolete versions of Audacity. The user "can" use two modern versions of Audacity by using a different profile with different temp dir. That said, 1.0.0 is very lightweight. If it works at all it probably won't have dropouts.
Our own documentation advises "Real-time recording is a very resource-intensive task for computers, which in most settings are not recording studios but multi-task machines with many competing demands on their processor. Therefore it's important to take steps to maximise available computer resources when recording." We see plenty of users on modern computers having difficulty making glitch-free recordings with just one audio application running - running two audio applications simultaneously is asking for trouble.
- Gale 27Mar16: Other things may be going on such as AV heuristics. Still if the user can record without dropouts with one app, in my experience and from what others have said they can probably do it in two applications if they must.
If the user is recording sounds that are playing on their computer, perhaps recording something from internet radio, and then run Audacity in the foreground to edit another project, just one simple mistake, such as catching the Ctrl key instead of the Shift key when adjusting a selection, will insert unwanted sound into their "background" recording and their recording project is instantly trashed.
- Gale 27Mar16: If they were recording in Audacity, and played audio in the other project they would actually stop the recording. For this case they should use a recording app that captures sounds direct from the application making the sound.
The "safe" way to make a recording and edit an Audacity project at the same time is to do the recording on different hardware.
If users actually want to record a "live mix", then there is software that is much more appropriate than Audacity for the job.
Can we expect Audacity to record without problems during intensive Hdd activity, as occurs when exporting a large project?
- Gale 27Mar16: For me, that works without dropouts on Windows 7 (HDD 2.4 GHz), as I said elsewhere.
If we allow multiple instances of Audacity, do we first check that the computer has multiple processors?
- Gale 27Mar16: This is one possibility.
On a single processor machine, a CPU intensive plug-in (such as a "convolution" effect) could easily be enough to cause an active USB audio stream to stop and/or crash.
It is generally seen as desirable among developers and users of Audacity that Audacity should make more use of multi-threading and multi-processor support. If we do this, which I hope we will, then the peak CPU load on modern multi-processor computers will, at times, be considerably higher than now, which will substantially increase the risk of skips and jumps in the background recording if editing another project at the same time.
- Gale 27Mar16: Multiple instances could be restricted to one core, I guess.
I have successfully recorded in a VM while recording something different on the real hardware - it's possible, but I wouldn't recommend it for any serious work. A much better approach would be two computers, which can be done using the same keyboard / mouse / monitor, either by secure shell or remote Desktop access. Alternatively the recording could be done on a stand-alone portable recorder. The total hardware costs to do the job "properly and safely" are actually lower than trying to force one high spec machine to do everything at once.
Regarding multiple projects / single "instance", there are numerous dire warning in the Audacity "Doxygen" code documentation about the risks of not handling the "pthread" (the audio thread) properly. Trying to handle audio IO operations in multiple projects at the same time is extremely problematic. Situations where it is allowed are invariably bugs. I don't see that it's possible to handle simultaneous audio in multiple projects (same "instance") safely without a major rewrite of the audio IO code.
- Gale 27Mar16: This may be why, with cautions, we might not want to prevent multiple instances of Audacity running. But currently the lock file on Mac/Linux is in the temp folder not the configuration folder, so we allow the possibility of multiple instances stepping on the same configuration. See https://bugzilla.audacityteam.org/show_bug.cgi?id=840 .
The "Single recorder/player model" is in my opinion, the safest most practical and most functional approach that we can take.
A wormcan issue reported by Gale on on the Forum - transferred here
Gale wrote on 02Aug14: Imagine two projects, one snapped to seconds and the other snapped to hh:mm:ss + hundredths. The .cfg file says
- Snap To=1
- Snap To=1
because those were the last changes for those two parameters.
Now, in the window that is snapped to hh:mm:ss + hundredths, uncheck Snap To and choose File > New. The new window opens unsnapped with the format on seconds. I think it would be more intuitive for the new window format to be hh:mm:ss + hundredths, i.e. if a parameter is changed, ensure that .cfg takes the value of the other parameter in the window where the parameter changed.
See Bug #749