Timing problems post Merge pull request #3081 from SunderB/patch/2022-05-09-cmake-copy-bin…

[rbnpi]

Both on latest Mac and RPi builds.
Try this program

use_bpm 60
#link

live_loop :test do
  puts current_bpm
  play scale(:c,:major).tick
  sleep 1
end

Runs OK as shown. Then uncomment link command and run again. Thread death Timing exception
Discovered by running example :bach. and then changing use_bpm 60 to link in that program.
Version 4 release works OK with this

[samaaron]

Hmm, that’s odd. If a fix is not immediately obvious I suggest reverting this commit for 4.0.1 and then looking into things in detail after that.

[rbnpi]

EDIT WRONG(Actually think Pi is OK) Pi has the same behaviour. Further investigation on Mac shows that midi i/o is not being detected. Also link externally is not working. Tau log shows.

      Powered by Erlang 25             
                                        
   Number of detected peers:           
   0 
                                        
   Current tempo:          
   60 
+--------------------------------------+



14:43:39.274 [info] 
+--------------------------------------+
    This is the Sonic Pi MIDI Server    
       Powered by Erlang 25             
                                        
   Detected MIDI input ports:           
   [] 
                                        
   Detected MIDI output ports:          
   [] 
+--------------------------------------+



14:43:39.275 [info] 
+--------------------------------------+
    This is the Sonic Pi OSC Server     
             == Tau ==                  
       Powered by Erlang 25             
                                        
        Incoming OSC on port 4560         
  OSC cue forwarding to {127, 0, 0, 1}              
                     on port 29444         
+--------------------------------------+



14:43:39.275 [info] 
+--------------------------------------+
    This is the Sonic Pi API Server     
       Powered by Erlang 25             
                                        
       API listening on port 29440         
+--------------------------------------+



14:43:39.277 [info] Running TauWeb.Endpoint with cowboy 2.9.0 at 127.0.0.1:29442 (http)
14:43:39.278 [info] Access TauWeb.Endpoint at http://localhost:29442
14:43:40.218 [info] API /send-pid-to-daemon -> sending pid to Daemon...
14:43:42.593 [error] Cue Server got unexpected message: {:midi_on, 1}
14:43:42.593 [info] Enabling cue forwarding 
14:43:43.326 [info] Enabling cue forwarding 

Still trying to ascertain which commit is causing problem.

[rbnpi]

Midi I/O devices are there, as earlier versions working. Is Tau [error] Cue Server unexpected message: {midi_on,1) relevant?

[rbnpi]

On my Mac I built 4.0 from scratch, then dropped the beam folder from that into a build of 4.0.1, replacing the beam folder there, as I don't think anything had changed for this, apart from the revamping of the build scripts. It then all worked. I suspect something may have gone amiss in the large revamp of the build process in recent merged sonderb commit. Going to try the same thing on my RPi build of 4.0.1

[rbnpi]

Same "solution" on RPi. I dropped in the beam folder from a working 4.0 build into a non working build of 4.0.1 It then worked fine. So it looks like there is an issue with the Tau (or possibly sp-midi or sp-link builds) following the changes between 4.0 and 4.0.1

[lilyinstarlight]

What happens if you only put libsp_midi.so and libsp_link.so from the working beam/priv folder into the non-working beam folder?

[lilyinstarlight]

Also, do you have any ideas @SunderB? I did a local revert of #3081 and it did fix the issue for me as well (but I can't investigate any more until later today)

[samaaron]

Apologies, I’m still travelling. Will look at this tonight and if the solution isn’t obvious (or already fixed) I’ll revert this for 4.0.1 and then we can have a bit longer to really understand what’s going on here.

[rbnpi]

I think there's several things going on. First the sp_link and sp_midi libs are named with dylib extension when built and installed by 4.0.1 version. I think they should be renamed to .so Secondly, the linux clean script uses the line
rm -rf server/beam/tau/priv/*.{so,dylib,dll} to remove old libs, but it doesn't work with the {so,dylib,dll}
deleting just with *.so did. This means that the first problem would be masked in rebuilds after a clean as the original libs were still left installed.
The actual libs appear to be identical for 4.0 and 4.0.1 builds as you would expect.
I copied the new libs to a 4.0 beam folder and they worked (when renamed to .so) However I think the remainder of teh folder for 4.0.1 doesn't copying a 4.0 beam folder into a 4.0.1 build does wkr, with the sp libararies built by either process.

have to go out now, but may look further later.

[lilyinstarlight]

@rbnpi The libs correctly end in .so for me. I figured out what's going on though, and it's related to them not getting copied into the _build folder in the beam distribution

See #3081 (review)

Thank you for doing your testing! Noticing that the beam folder was what gets messed up definitely pointed me in the right direction, and I noticed the issue when doing a diff -r between a good and bad beam folder

[samaaron]

I think the issue with the .so extension is that macOS typically uses .dylib but the BEAM weirdly requires them to be .so see:

sonic-pi/app/mac-pre-copy-binaries.sh

Line 16 in 85782ca

cp "$f" "${SCRIPT_DIR}"/server/beam/tau/priv/$(basename "$f" .dylib).so

[samaaron]

Unless anyone sees that there's a super quick and reliable fix for this - I think it's probably sensible to roll back for 4.0.1 then look at it again. Any thoughts?

[SunderB]

@samaaron I’ll have a look into this and see if I can see anything obviously wrong

[rbnpi]

Yes the name problems was on my Mac. linux/rpi is OK here.