Server doesn't create RPP file when closed

[Snayler]

I've noticed that the server doesn't create the Reaper Project file when we close it. It would be nice to have it create the RPP file when closed so that we can restart the server and keep the project.

EDIT: Can anyone tell me if the generated wav filenames have information that can help me put the channels together on a Reaper project?

[pljones]

The RPP is only created if a jam ends cleanly. I've a script that can cobble a project file together.
recover-recording.zip
(Obviously check through for my local path names.)

Unfortunately, closing the server doesn't end the jam - or anything else - all that cleanly. If using the GUI, I think I spotted somewhere that might be fixable, but for command line, I was stumped (and I use command line...).

[Snayler]

I'm currently using the GUI, so it would be a nice addition to me. Wouldn't it be possible to trap a CTRL+C signal on command line?

EDIT: Ignore the previous edits, I've managed to get everything working. Documenting the process here for future reference.

I've tried your script and I managed to make it work by manually inputting the variables. Since I'm on Windows, I couldn't provide a init_script path, so I had to adjust the script accordingly. It didn't seem to work as I expected initially. I was running the script from a Manjaro install I have on a different disk on the same computer.

I commented out the "Get the variables" section and proceeded to manually add the server name:

JAMULUS_SERVERNAME="Snayler's Jam[3.5.1]"

I also changed projectName to the name of the folder containing the "failed" recording, since the original command $(basename $(pwd)) has a problem with spaces on the directory.

After opening the project on Reaper, the tracks were not timed as they should be and the tracks were repeating. I managed to get the timing correct by changing the buffer size in secondsAt48K from 128 to 64. I assumed this was necessary because my server was running in --fastupdate mode (no need for this if the server isn't in 64 mode), seems like it was a correct assumption. To solve the repeating tracks issue, I just had to edit:

echo ' LENGTH '$(secondsAt48K $(( $fileSize / 64 )) )

And change 64 to 256. I arrived at the 256 value by trial and error (went from 64 to 128, and finally, 256), since I don't fully understand where that value comes from. I just thought that if the length was bigger than expected (resulting in the repeating tracks), I just had to increase the value in order to decrease the length.

After these changes, the script produced the correct file, all the tracks are timed correctly with the correct length. Thank you very much for the script, pljones!

[pljones]

Shame the quotes around $(basename) didn't help on Windows...

Ah! Yes, I'd forgotten the script would need to handle --fast-update - thanks!!

+frameRate=$([[ ${JAMULUS_OPTS[@]} =~ " -F" ]] && echo 64 || echo 128)
+
 secondsAt48K () {
-       echo $1 | awk '{ printf "%.14f\n", $1 * 128 / 48000; }'
+       echo $1 | awk '{ printf "%.14f\n", $1 / 48000; }'
 }

and

-       filePos=${x#*-*-}
-       filePos=${filePos%-*.wav}
-       echo '   POSITION '$(secondsAt48K $filePos)
-       fileSize=$(stat -c '%s' "$x")
-       echo '   LENGTH '$(secondsAt48K $(( $fileSize / 64 )) )
+       filePos="${x#*-*-}"
+       filePos="${filePos%-*.wav}"
+       echo '   POSITION '$(secondsAt48K $(( $filePos * $frameRate )) )
+       echo '   LENGTH '$(secondsAt48K $(soxi -s "$x"))
+       echo '   IGUID {'$(uuidgen -n $projectNamespace -N $IP --sha1)'}'

I also noticed IGUID is missing (Reaper clearly doesn't mind) and I can't remember if there was a good reason (i.e. I couldn't work out how to make it "right" and didn't want it wrong) or not (i.e. I missed it unintentionally). But I've added it.

[Snayler]

Shame the quotes around $(basename) didn't help on Windows...

I just did a quick and dirty test on an online terminal emulator, it seems to work if you enclose the $(pwd) in quotes:

projectName=$(basename "$(pwd)")

[pljones]

Back to the main topic, though. SIGINT / SIGTERM should cause Jamulus server to gracefully exit, disconnecting each client and thus ending any recording in process beforehand.

Something like the method described here is likely to be needed.

[sthenos]

Sorry to hijack this thread, but it is relevant to me just to understand the recording process. So the only way to get a clean recording is to: 1. bring the server up with recording option on. 2. Ask clients to connect to the server and do their performance. 3. Tell all clients to disconnect from server. If I stop and start the server turning on and off the recording option while clients remain connected, this would not work?

[Snayler]

@sthenos if you stop the server while the recording is undergoing (meaning there's still clients connected), the server will keep the recordings for all channels up to the point of when you stopped it. It will just not create the RPP file necessary for Reaper to correctly place the sound files at the correct times and in the correct channels.

[pljones]

I've done a first pass through the code based on a few bits and pieces and I've got a second reduction up pass to do, followed by a final clean up pass, then I can start testing it. It should work on Windows and Linux (and, given MacOS is *nix-like enough, there too).

Unfortunately, I've been a bit burnt out from "real work" this past week or so.

[pljones]

The mostly cleaned up version now seems to be working on Linux. I expect the GUI shutdown on Windows to work, too (as that's a QT signal to slot handler). I've got to test that and the command line handling on Windows, though. Might get it done today.

https://github.com/pljones/jamulus/tree/feature/130-signal-handling

The code is "based on" (i.e. I ripped apart and put back together) an example that covered both Windows and Unix signals and more "nicely" than the examples the Google is currently returning -- but of course, now I can't find it again.

[pljones]

Except that the Windows version seems to run in the background, might have been nice for that not to happen:

It's rather messy from the command line...

EDIT: Hm... I can't see anything in the code putting it in the background nor can I find any documentation saying anything useful one way or the other. So I can't test the Ctrl-C handling on Windows: the Close button calls the handler, though.