Perhaps worth trying a much earlier version of Audacity to see if that’s any better. Old versions are available here: https://www.fosshub.com/Audacity-old.html
I tried using an earlier version of Audacity and now it seems like I cannot get to open a pipe between MATLAB and Audacity. I am getting the following error:
Is mod-script-pipe enabled in Audacity’s Preferences?
Which version of Audacity? Version 2.4.2 works well for me, but of course YMMV.
Thank you for your responses, Steve. So, while using an older version (v3.1.3), I was able to open a pipe between MATLAB and Audacity. I am using a Python virtual environment and when I open Audacity inside of the environment, I cannot open a pipe; when I open Audacity normally, I am able to open a pipe. However, even with this older version, I still get the above read error. I will try v2.4.2 as you suggested and get back to you.
In case it’s important / relevant to the task in hand, note that Audacity 2.4.2 uses the old “AUP file + _data folder” project format rather than the new SQLite based “AUP3 file” project format. Audacity 2.x cannot open projects created by Audacity 3.x, though Audacity 3.x “should” be able to open projects created with Audacity 2.x.
Hey Steve, I have a quick question. What happens to the pipe when you close the Audacity project? When you close a project and the new (blank) project opens, can the previously-existing pipe still be used to send commands?
I’m guessing no, but I rarely use Windows, and named pipes are implemented differently than in other OS’s, so that’s just a guess.
On Linux (the OS that I use), the pipe is created by the server side app (Audacity), and then the client side app (Python) can connect to it. If either side of the pipe closes, the connection is broken. Even after closing both ends, the pipe still exists (rather like a zero byte file in the .tmp directory) but the ends of the pipe are not connected to anything.
If only the client app (Python) is closed and Audacity remains open, then the client app may be restarted and it will be able to reconnect to Audacity.
If only the host app (Audacity) is closed and the client remains open, then restarting Audacity will NOT connect to the client. The client must be restarted after Audacity has launched.
Try it yourself and see what happens
I recently updated to v3.2.3 and now I get a slightly different reason for Audacity crashing; the program says there is an exception stack overflow. It seems that with each (or some) calls to pipeclient, my code causes Audacity to generate an exception. I will have to check each command I write to the pipe to see which are responsible.
Hey Steve. Is there any way to see Audacity’s exception stack? I think Audacity can raise an excepion but continue to work anyway (without explicitly signalling that an exception has occured), which means I may have some difficulty in telling which commands cause the exceptions. Maybe if I cannot see the stack, there may be an option to get an alert for every exception that occurs? Please tell me if I am making sense here, lol.
To debug Audacity, you would need to build a debug version from the source code.
I’ve not built on Windows for a long time (I use Linux), so I’m not able to help you with this other than pointing you towards the current documentation.
Building from source code is tricky on Windows as it requires a lot of stuff to be installed to create a development environment. Instructions for building are here: https://github.com/audacity/audacity/blob/master/BUILDING.md
Thank you so much…I’ll definitely give it a try! Also, I was just thinking that maybe I could read from the pipe to see if the exceptions are being sent there…if they are, I could try to debug using that info. I will be sure to give you an update on how things turn out.
So I tried building Audacity on Windows using cmake and VS 17 but there was a problem with opening the .sln file to do the build. I will have to try an alternative like monobuilder for the build phase.
I have a really silly question to ask though. Will trying to select all the tracks in a project raise an exception if all the tracks are already selected?
It’s monodevelop I meant, not monobuilder. My apologies for that mistake.
Not sure what happened to Steve…
No - I can’t see why it should.
There is building information as well as a link to the developers discord channel here: Home · audacity/audacity Wiki · GitHub
Note that your issue looks similar to this one here: Batch Process Macros Read Error
They are indeed similar…one with a macro while the other with scripting but essentially the same error. Not sure if this will be useful: I am back to getting the exception_ access_violation_ read error but I’ve managed to make some progress (I’m not entirely sure why though).
One of the things I did was to add pauses to my code to allow commands to complete (waiting for a response) before sending another command. I also tried deleting the old audacity.cfg file to reset the preferences (two preferences, including no warning when saving empty projects, were redone out of necessity).
The outcome was that Audacity ran for a significantly longer time (more data was produced) before crashing. It still crashes though, so the search for a proper solution continues.
Thanks for the report. Good luck! Keep us posted…
Maybe you’re overflowing one of the pipe buffers?
That is very plausible…at the moment, I am checking to see if adding more pauses between commands will give Audacity the time it needs to execute without flooding the pipe.
This is just a guess…
Are you reading from the FromSrvPipe pipe, or only writing to the ToSrvPipe?
I’m not sure exactly how this works, but I believe that Audacity sends a bit of data to the “FromSrvPipe” each time that you send a command, so my conjecture was if your script doesn’t read from that pipe, its buffer will eventually become full.
Recently I started waiting for a response from the FromSvrPipe pipe, then reading that response, before sending another command across the ToSrvPipe pipe. That seemed to have lengthened the uptime of the pipe.
You may be on to something. I am learning as I go along.