I've got this working now! In the version I had there is a small bug/typo which prevents the sliders and toggles from updating.
In the netbus.pd file there is an abstraction on the send side, pd oscformat Inside it there is a message box 'set /syncjams$1' I think this needs to read 'set /syncjams/$1' or the route object on the receive side doesn't do what it is supposed too. Annoyingly I haven't managed to get adb access to my device yet - it is reported as offline and I lost the will to live trying to find out why. But luckily I worked out what I needed to get syncjams to work. The latency on my device, a Moto G, seems to be around 100ms. The ping time from my laptop to my phone is 3ms so I guess I can pretty much discount that! On Thu, Dec 11, 2014 at 11:32 AM, Gavin <[email protected]> wrote: > > Thanks for your comprehensive reply. > Hopefully this conversation should now be on list. > > Syncjams looks very interesting I will try it out today! > I opened it on my laptop and it seems I need the netsync object. I have > found the repository on github - do I need to grab this? > > Or is netsync bundled with pddroidparty? Which is the latest version? - is > downloading 276 from the website sufficient or so I need to download it > from github and compile it or something? > > I'm finding it a bit difficult to know if the objects are missing on my > phone. Bit of a noob at this. It's like blind coding! > > I realised that Android has severe audio latency issues but I thought > these were largely when using audio in. I thought my latency was largely > created by the network but now I am questioning this. In any case yes your > audio approach seems like a fair solution. Hopefully lollipop will improve > this and in about 5 years it will be universally adopted! > > Right I'll try and get syncjams to work - I'm currently using 1 phone and > 1 laptop - if for some reason this will never work and I need to use 2 > devices, please someone put me out of my misery! > > > > > On Thu, Dec 11, 2014 at 2:08 AM, Chris McCormick <[email protected]> > wrote: > >> Hi Gavin! >> >> On 09/12/14 19:27, Gavin wrote: >> > Is it ok to email you about this or would you prefer to keep it to the >> > forums? >> >> I hope you don't mind me CC'ing this to the Pd-list. >> >> I'm happy you emailed about this because it is exactly what I have been >> working on lately when I find spare time. >> >> > I'm a bit confused as to the network options with pddroidparty. >> > There is netro which seems to be based on netsend and x-netreceive but >> > also droidnetreceive and also netreceive! >> > Which is the recommended or latest one? >> >> The native netsend and netreceive now work in the version of Pd that >> ships with PdDroidParty. The other libraries are deprecated. Sorry for >> the confusion - there was a long standing bug with netreceive not >> working in libpd that is now resolved. x-netreceive was just my way of >> commenting out netreceive - you can change it back to netreceive and >> remove the top level droidnetreceive hack object and netro should just >> work again. >> >> Netro is an abstraction for doing timing synchronisation of Pd patches >> that runs on top of netreceive. I haven't updated it for a long time >> because I've been working on something that does the job better: >> >> http://github.com/chr15m/SyncJams/ >> >> SyncJams uses OSC underneath and so it can interoperate more widely with >> other software. There is also a Python implementation and I am hoping >> for implementations in other languages (especially Supercollider) down >> the track. Patches welcome! >> >> SyncJams provides a way to not only sync metronomes during live >> performance but also a sort of distributed hash table ("set-state") >> where everybody involved in a jam can share state information like >> controller position, song key, etc. There is also a generic conduit for >> in-time events ("message") to be propagated in order such as drum beat >> hits from a live drummer. >> >> I've been testing on Android, and latency aside things are working >> pretty smoothly now. >> >> > Also is there anyway to debug/print to a console on a phone? >> >> If you use Pd's print object you can then use `adb logcat` to see what >> comes out - you'll need to have your phone in debugging mode and >> connected via USB or over TCP to adb. >> >> > I'm hoping to guesstimate latency by calculating the time it takes to >> > send data from one device to another and back and sync phasors on >> > separate devices. >> > >> > Have you tried this? >> >> So latency is the exact problem I am tackling at the moment. >> >> After speaking to Peter Brinkmann, the resident Android audio expert, >> the outlook is as abysmal as ever. The way audio is implemented on >> Android means you can't ever really know with 100% certainty how long it >> takes between a software event and the speaker actually emitting the >> triggered sound. >> >> My approach, which is hopefully "good enough" is similar to what you >> suggest, except that a single device can send a signal to its own >> microphone to measure the round trip time. Hopefully half of the round >> trip time will give the approximate output latency. This is what the >> android-latency-tester patch did and I will probably use that same >> method (with the bonk~ object). >> >> <http://puredata.info/docs/AndroidLatency/> >> >> I tested a FFT based cross correlation approach to detect the >> same-device latency, but it wasn't really robust enough. That is in the >> SyncJams repository if you want to take a look. Maybe I did something >> wrong though as my DSP math is not very strong. >> >> There is also Raph Levien's audio buffer size tool: >> >> https://play.google.com/store/apps/details?id=com.levien.audiobuffersize >> >> Which uploads its results for different devices: >> http://audiobuffersize.appspot.com/ >> >> Code: >> >> https://code.google.com/p/high-performance-audio/source/browse/audio-buffer-size/src/com/levien/audiobuffersize/AudioBufferSize.java >> >> In the end I think the approach on Android is going to be: >> >> * Alert the user the first time they run the patch that latency needs >> to be tested. >> * "Please turn up your speakers while we run the test." >> * Collect the timing data using bonk~ or FFT cross correlation or >> whatever and write it to disk. >> * Everybody who makes an Android Pd app can use the same filename, >> location, and format for the data (/sdcard/Pd/latency-test.txt) so >> hopefully it only has to be done once. >> * Use the values in that file to compensate for latency. >> * Provide a menu option for the user to re-run the compensation if they >> feel latency is getting out of hand. >> >> > PS One more thing - where can I get x-netreceive so I can install it on >> > my laptop. Is it the same as xnetreceive? >> >> x-netreceive is not a real object - it's what I used to comment out the >> existing netreceive object in netro when that wasn't working under >> PdDroidParty. What you can do is replace it with netreceive instead, and >> remove droidnetreceive entirely. Things should work after that. >> >> Let us know how you go! >> >> Cheers, >> >> Chris. >> >> -- >> http://mccormick.cx/ >> >> > > > -- > Gavin > www.digitalfunfair.co.uk > -- Gavin www.digitalfunfair.co.uk
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
