Live-Looper with touchOSC control

#8

Have you tried comms between the phone TouchOSC and something else? Worth running the puredata example form the documentation which can test both ways I think.

1 Like

#9

Hi Robin,

I can’t check right now, but tomorrow.

I do not have touchOSC bridge. It is the equivalent to the touchosc2midi python script I ran but don’t need, right? If yes, there is no IP that could be configured there…

Can’t install PD on Linux. It requires/installs aubio4.1; after installing Sonic Pi refuses to run. Did this a few days ago and it took me a while to realize what was going on.

Initially I checked with oscdump (but this does only check one direction). There’ll be probably something else with wich I can send osc… I’ll let you know.

Thanks again!

0 Likes

#10

Found a commandline tool with which I can send osc from my linux box (send_osc). The phone does not receive anything. Tried the same also with Control, same result.

I guess you are right and it is a communication problem linked to my Android (with EMUX)j or WLAN. Did also some unsuccessful Google search concerning this one-way-communication.

Could it be that my router passes osc messages just one way? Is there an Android setting blocking incomming osc messages?

But, also without communication backwards to the phone the live looper is usable.

0 Likes

#11

I have no knowledge of Android so can’t help here. Maybe you could raise something on the hexler.net site forum?
Have you checked that Sonic Pi can send OSC successfully on your system, to another receiving program? eg on ubuntu could use https://apps.ubuntu.com/cat/applications/pyliblo-utils/

0 Likes

#12

That is actually a very good idea. I did try to send from Sonic Pi with:

use_osc "192.168.2.120", 9000
live_loop :test do
  osc "/rec/track1_play",1
  sleep 2
  osc "/rec/track1_play",0
  sleep 2
end

as well as:

use_osc "localhost", 9000
live_loop :test do
  osc "/rec/track1_play",1
  sleep 2
  osc "/rec/track1_play",0
  sleep 2
end

and listened with oscdump. Nothing received.

But I can send with send_osc and listen with osc_dump.

I do get a repeating error in the erlang.log:

Error in process <0.136.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}
udp server timeout:69
udp server timeout:70  

I have also an error in `osmid_o2m.log:

sh: 1: [my_sp_install_path]/app/server/native/linux/osmid/o2m-L: not found

Maybe this is a hint?

0 Likes

#13

both the erlang osc files and osmid have had updates which may not have been flagged on the SP github site. Might be worth rebuilding the erlang beam files using erlc and also checking you have the latest osmid binaries.

0 Likes

#14

Did recompile the erlang files and compiled the lates osmid binaries.

Still the same error messages in the logs. Does it make sense to create an issue at Github? I do not know.

Same result concerning osc messages. Sonic Pi does not seem to send them out.

0 Likes

#15

Are you building the very latest from SP github repro or the release settings for 3.0.1?
There IS an issue that I have found with the latest which prevents Mac from working. It is because of commits on 16th September Erlang -use -noshell flag when starting process and osmid _teach o2m to use loopback network. These both stopped Mac from working. If you manually change them back (no need to rebuild aprt from redoing erlc for the relevant erlang file). See if that helps. I think they were put in to try and improve Windows version behaviour.
The full numbers for the commits were
51570a3d413df9e07a0246da3e6442e6b1559ec5
and
0c1e9e402463f09c4b0f7a7f66475b6d46148817

This may be your problem.

NB SEE NEXT POST FOR A CORRECTION

0 Likes

#16

OOPS I think I put the wrong ERLANG change commit. IT should be the one
Erlang - tech scheduler to only listen on loopback network
number dedc9ea6cfbf6e8c6d02e48196c5cb23c93e0b55
NOT the one I mentioned for Erlang above. It has the same date.

0 Likes

#17

I am a bit embarrassed to ask: I guess you are advising me to go back to a previous commit (better the 2 that you mentioned), fetch the erlang related files (pi_server.erl and osc.erl) and exchange these in my 3.0.1 installation (which acctually is the commit about two weeks ago), right?

If yes, I haven’t done this before so I don’t know how this works… I will follow this ressource:

0 Likes

#18

You could do that, but In my case I just looked at what the commits did, which were very simple changes and I edited the two files directly.
The two changes are in studio.rb line 695 was changed from

o2m_spawn_cmd = "'#{osmid_o2m_path}'" + " -b -i #{@midi_osc_out_port} -O #{@midi_osc_in_port} -m 6"

to

o2m_spawn_cmd = "'#{osmid_o2m_path}'" + "-L -b -i #{@midi_osc_out_port} -O #{@midi_osc_in_port} -m 6"

Change it back again

and
in pi_server.erl line 69

{ok, Socket} = gen_udp:open(Port, [binary]),

was changed to

{ok, Socket} = gen_udp:open(Port, [binary, {ip, loopback}]),

again change it back again, but in this case you will then have to rebuild it using
erlc pi_server.rlc to produce an updated pi_server.beam file

The studio.rb file is in /app/server/sonicpi/lib/sonicpi

If you want you can keep the original files elsewhere.

0 Likes

#19

Ok, that was clear. Done.

The message from osmid_o2m.log obviously is gone now. But I get still the errors in the erlang.log (I did erlc the file pi_server.erl):

=ERROR REPORT==== 1-Nov-2017::19:27:35 ===
Error in process <0.216.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}

Did you get rid of these?

0 Likes

#20

I don’t get this erlang error. If you are still not getting the exteranl OSC messages from Sonic PI working then I suggest it may be worth raising it as an error on github, (the error message you are getting. Can you ascertain WHEN it occurs? Is it as a result of an osc message sent from SP?

Also perhaps I’ll ask @samaaron to comment on this thread The error messages certainly looks like something is being delayed.

0 Likes

#21

@robin.newman, thanks a lot for you patience and help!

Yes, I do get the errors after sending osc messages from Sonic Pi:

Sonic Pi code:

use_osc "192.168.2.120", 9000
live_loop :test do
  osc "/rec/track1_play",1
  osc "/rec/track2_vol",0.5
  sleep 2
  osc "/rec/track1_play",0
  osc "/rec/track2_vol",0
  sleep 2
end

Sonic Pi-protocol:

=> Starting run 1
=> Defining fn :live_loop_test
{run: 1, time: 0.0}
 ├─ OSC -> 192.168.2.120, 9000, /rec/track1_play, [1]
 └─ OSC -> 192.168.2.120, 9000, /rec/track2_vol, [0.5]
{run: 1, time: 2.0}
 ├─ OSC -> 192.168.2.120, 9000, /rec/track1_play, [0]
 └─ OSC -> 192.168.2.120, 9000, /rec/track2_vol, [0]
=> Stopping all runs...
=> Stopping run 1
=> Completed run 1
=> All runs completed
=> Pausing SuperCollider Audio Server

Errors in erlang.log:

+--------------------------------+
+ This is the Sonic Pi IO Server +
+       Powered by Erlang        +
+     Listening on port 4560     +
+--------------------------------+

=ERROR REPORT==== 1-Nov-2017::20:13:45 ===
Error in process <0.33.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}

=ERROR REPORT==== 1-Nov-2017::20:13:45 ===
Error in process <0.34.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}

=ERROR REPORT==== 1-Nov-2017::20:13:47 ===
Error in process <0.35.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}

=ERROR REPORT==== 1-Nov-2017::20:13:47 ===
Error in process <0.36.0> with exit value:
{badarg,[{erlang,system_time,[nanosecond],[]},
         {osc,now,0,[{file,"osc.erl"},{line,54}]},
         {pi_server,send_later,7,[{file,"pi_server.erl"},{line,177}]}]}
0 Likes

Polyrhythmic Drum Generator for Sonic Pi
Possibility to start a buffer from another buffer
#22

ON final possibility. At one time the fast_osc binary was giving problems, and I reverted to disabling that by changing a line.
I see from my server errors log that I still hve it disabled

Overriding fast_osc c-extension FastOsc::decode_single_message, falling back to pure Ruby version

I can’t remember where I disabled it, and have to go now, but will check and let you know later.

0 Likes

#23

Found the change
in the vendor fast_osc folder open fast_osc.rb
Then change line 38 to
if true #ENV['FAST_OSC_USE_FALLBACK'] == "true"
This forces it to ignore using fastosc
sp still works OK

0 Likes

#24

Yes, no more erlang errors. But does not affect the initial problem: No osc messages from Sonic Pi.

0 Likes

#25

Another simple test to try;
can you send osc messages to yourself using

use_osc "localhost",4559

live_loop :tx do
  use_real_time
  osc "/test"
  sleep 1
end

live_loop :rx do
  use_real_time
  sync "/osc/test"
  puts "received"
end

Also if you have access to another Sonic Pi machine (perhaps a raspberry pi?) can you send messages to and from that?

0 Likes

#26

Did check with Mac (SP 3.0) and Linux (SP 3.0 and 3.0.1). Turns out, that I can both receive and send osc messages when using SP 3.0; now also working with touchOSC. My checkout of SP 3.0.1 does receive but not send osc messages.

Many thanks to you @robin.newman. Especially the last tip lead me to this - preliminary - solution.

Should I create an issue about that on Github, or are these kind of transient issues not worthwhile to mention?

1 Like

#27

I assume your 3.0.1 (maybe post 3.01?) build is on Linux, in which case I don’t think it helps to put it on github just now.
I reverted to fast_osc on my Mac and it worked fine there without giving erlang errors. I think the problem initially rose on RPi, and I’ll need to check if it is disabled there or not. There were worse crashing errors during development of SP3 related to this.
Glad it is working for you on 3.0 on LInux.
As I said earlier, the problems I’ve had are with commits AFTER 3.0.1 release as detailed previously, and I think I told Sam about them.

0 Likes