I made a server plugin for a piece I premiered recently with @Sam_Pluta. Here is a link to the repo branch with the source files. The main branch does not include the source.
I am on an Intel machine and have had no issues with the plugin. The first time I sent it (I only sent the plugin folder), it didn’t work for Pluta because I hadn’t built it for arm and he is on an M1 machine. I sent him the source and also rebuilt it to try to fix it:
cmake -DCMAKE_INSTALL_PREFIX=/Users/josiahsytsma/Library/Application\ Support/SuperCollider/Extensions -D CMAKE_OSX_ARCHITECTURES="x86_64;arm64"
I sent it to my dad who has an M1 to see if it would work for him, and it did. Pluta built it from the source after I had sent it to him previously and said that it worked.
In rehearsals, Pluta said that the server was crashing and stopped crashing only when the plugin was removed.
Any suggestions?
Side note: don’t use macros like ZXP. They are not necessary (anymore) and make the code impossible to read without looking up the macro definition.
Right. I used a stable ugen as a template, just to make absolutely sure I knew it was going to do the right thing since this was my first plugin.
That being said, I don’t see a problem with your code.
I think you (or Sam) would really need to attach a debugger and get a stacktrace. However, even then you might not really know who is responsible for the crash. Since the RT memory pool is just one large continuous block of memory, ugens typically don’t immediately segfault on out-of-bound memory access, instead they overwrite some part of another ugen. In your case, it may very well be the case that another ugen is writing past its bounds and just happens to mess with your plugin.
Here’s another trick: if you compile scsynth with -DDISABLE_MEMORY_POOLS, the RT memory pool would just call malloc and free. Obviously, this wouldn’t be realtime safe, but at least you get an actual segfault on out-of-bound memory accesses.
I don’t know what was causing the crash, but it stopped happening when I took your UGen out of my system. That being said, I decided to go forward with the concert without it purely for pragmatic reasons. We had no time to debug and there were 4 complicated pieces on the show that all had different tech setups. The issue was more time than anything else. Had there been time to debug, I imagine a different culprit may have appeared.
I actually imagine that the crash might have been resolved after I switched from 96K to 48K, which I had to do at some point anyway (I just don’t remember if this was before or after I was having crashes). Apparently my software works fine on my UCX at 96K, but starts to bog down with the UFX+ in use.
Victims: all of us
Offender: father time
Sam
1 Like
Totally understood and I thought it was 100% the right decision. I just wanted to see if there was something weird I had done in the design/build that might have caused the issue since I plan to use it later for other projects.