hi all
We need a chronometer that runs in sync in multiple devices at the same time. Target platform is android, and if possible iOS as well. We are thinking also that it would be great to have some sort of metronome running together with the chronometer (we have trained musicians together with non trained musicians in the ensemble).
So far we have been using http://chronograph.io/ so far but it is not 100% reliable, we had a few issues last performance (one device was ~1 sec behind the others, and often during rehearsals we had problems with the start signal not being sent at all).
I am considering the possibility of implementing this functionality in PD using PDdroidparty and OSC. Because we dont like the tools we have found online. We found some nice metronomes but the only one that seems to sync is only iOS. And we do need the chronometer (in fact priority n1 is the chronometer right now). I thought maybe someone can point into some existing alternative before I try to reinvent the wheel.
One of the biggest issues I foresee is to find an easy and quick way for the master device to find out the available slaves in the network. I would not like to have to, one by one, find and then type the IPs of each single device in the master device, although the master could be a laptop running PD and that would make it easier to type them...
thanks in advance for any feedback
enrike
Hi Enrike,
you'll probably find that syncing many devices together (especially via a wifi network) is a rather difficult task. Many parameters can make it complicated, above all network latency and device latency. Network latency is often quite variable and unpredictable, and the same goes for audio latency on Android.
That said, it seems that the best solution currently is Ableton Link ( https://www.ableton.com/en/link/), which is a GPL cross-platform library and protocol. It is implemented to Pd through the [abl_link~] object (available from Deken for most platforms).
In some case where [abl_link~] wouldn't work (I had crashes on a raspberryPi), you can use Carabiner which provides a network socket to Link: https://github.com/Deep-Symmetry/carabiner
good luck!
Le mar. 5 mars 2019 à 17:18, enrike altern2@gmail.com a écrit :
hi all
We need a chronometer that runs in sync in multiple devices at the same time. Target platform is android, and if possible iOS as well. We are thinking also that it would be great to have some sort of metronome running together with the chronometer (we have trained musicians together with non trained musicians in the ensemble).
So far we have been using http://chronograph.io/ so far but it is not 100% reliable, we had a few issues last performance (one device was ~1 sec behind the others, and often during rehearsals we had problems with the start signal not being sent at all).
I am considering the possibility of implementing this functionality in PD using PDdroidparty and OSC. Because we dont like the tools we have found online. We found some nice metronomes but the only one that seems to sync is only iOS. And we do need the chronometer (in fact priority n1 is the chronometer right now). I thought maybe someone can point into some existing alternative before I try to reinvent the wheel.
One of the biggest issues I foresee is to find an easy and quick way for the master device to find out the available slaves in the network. I would not like to have to, one by one, find and then type the IPs of each single device in the master device, although the master could be a laptop running PD and that would make it easier to type them...
thanks in advance for any feedback
enrike
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hello Enrike,
On 6/3/19 12:18 am, enrike wrote:
We need a chronometer that runs in sync in multiple devices at the same time.
SyncJams might work for you:
https://github.com/chr15m/SyncJams
The algorithm it uses is tolerant of adverse network conditions. All devices run their own internal clock and the clocks converge on a consensus "current tick".
The algorithm is very simple: every device broadcasts its current tick over the network. If a device receives a tick which is higher & earlier than it expected it immediately resets its own clock to that new timing.
What this means in practice is the smallest (i.e. best) point-to-point ping time between any two participating patches is the closest that the clocks will get in sync. On a WiFi LAN this is generally on the order of 1 to 3 milliseconds which is close enough for most musical applications. In my experience devices converge on that value quite quickly after joining the network.
Here's a video of Chris Rice aggressively changing the BPM from which the devices manage to recover after a second or two:
https://www.youtube.com/watch?v=yNvD-KQhR9k
Here are two Android devices syncing:
https://www.youtube.com/watch?v=Z5tlEZwttBM
I've been planning to revisit the project to simplify it and port to Supercollider etc. for some time but who knows if I'll ever get around to that.
Cheers,
Chris.
thanks to everyone for the answers. this looks interesting and I will start exploring here. Ableton link seems like another option too
19/3/6 04:13(e)an, Chris McCormick igorleak idatzi zuen:
Hello Enrike,
On 6/3/19 12:18 am, enrike wrote:
We need a chronometer that runs in sync in multiple devices at the same time.
SyncJams might work for you:
https://github.com/chr15m/SyncJams
The algorithm it uses is tolerant of adverse network conditions. All devices run their own internal clock and the clocks converge on a consensus "current tick".
The algorithm is very simple: every device broadcasts its current tick over the network. If a device receives a tick which is higher & earlier than it expected it immediately resets its own clock to that new timing.
What this means in practice is the smallest (i.e. best) point-to-point ping time between any two participating patches is the closest that the clocks will get in sync. On a WiFi LAN this is generally on the order of 1 to 3 milliseconds which is close enough for most musical applications. In my experience devices converge on that value quite quickly after joining the network.
Here's a video of Chris Rice aggressively changing the BPM from which the devices manage to recover after a second or two:
https://www.youtube.com/watch?v=yNvD-KQhR9k
Here are two Android devices syncing:
https://www.youtube.com/watch?v=Z5tlEZwttBM
I've been planning to revisit the project to simplify it and port to Supercollider etc. for some time but who knows if I'll ever get around to that.
Cheers,
Chris.
I already have a test version running! nice. I used PDdroidparty and I get a phone and two computers running the same chronometer in sync. there are some issues I need to check yet but it seems this like this is the right direction to go. I will dump the code into github when it is useable.
(I am fighting now with PdDroidPublisher as we would need to have an apk that we can just install into participants mobiles. The PdDroidPublisher documentation is outdated as far as I can see and I far from being an expert in Android Studio configuration, lets see)
enrike
19/3/6 04:13(e)an, Chris McCormick igorleak idatzi zuen:
Hello Enrike,
On 6/3/19 12:18 am, enrike wrote:
We need a chronometer that runs in sync in multiple devices at the same time.
SyncJams might work for you:
https://github.com/chr15m/SyncJams
The algorithm it uses is tolerant of adverse network conditions. All devices run their own internal clock and the clocks converge on a consensus "current tick".
The algorithm is very simple: every device broadcasts its current tick over the network. If a device receives a tick which is higher & earlier than it expected it immediately resets its own clock to that new timing.
What this means in practice is the smallest (i.e. best) point-to-point ping time between any two participating patches is the closest that the clocks will get in sync. On a WiFi LAN this is generally on the order of 1 to 3 milliseconds which is close enough for most musical applications. In my experience devices converge on that value quite quickly after joining the network.
Here's a video of Chris Rice aggressively changing the BPM from which the devices manage to recover after a second or two:
https://www.youtube.com/watch?v=yNvD-KQhR9k
Here are two Android devices syncing:
https://www.youtube.com/watch?v=Z5tlEZwttBM
I've been planning to revisit the project to simplify it and port to Supercollider etc. for some time but who knows if I'll ever get around to that.
Cheers,
Chris.
Hi Enrike,
On 7/3/19 5:17 am, enrike wrote:
(I am fighting now with PdDroidPublisher as we would need to have an apk that we can just install into participants mobiles. The PdDroidPublisher documentation is outdated as far as I can see and I far from being an expert in Android Studio configuration, lets see)
If you can get the PdDroidParty apk installed on the devices then it's
possible to distribute the patch as a zip file to the devices quite
easily. You can zip the patch folder and then rename the zip so it has a
.dpz extension. If a user has PdDroidParty installed and they receive
a .dpz file by email or click on a link to a .dpz file then it should
automatically open in PdDroidParty.
This still means you have to install two things (the DroidParty apk and the .dpz file) but maybe it's easier than creating a custom apk and easier than copying the folder onto SD cards one by one.
More info about this can be found in the "Sharing your patches" section on the droidparty.net site.
Cheers,
Chris.
(I am fighting now with PdDroidPublisher as we would need to have an apk that we can just install into participants mobiles. The PdDroidPublisher documentation is outdated as far as I can see and I far from being an expert in Android Studio configuration, lets see)
If you can get the PdDroidParty apk installed on the devices then it's possible to distribute the patch as a zip file to the devices quite easily. You can zip the patch folder and then rename the zip so it has a
.dpzextension. If a user has PdDroidParty installed and they receive a .dpz file by email or click on a link to a .dpz file then it should automatically open in PdDroidParty.This still means you have to install two things (the DroidParty apk and the .dpz file) but maybe it's easier than creating a custom apk and easier than copying the folder onto SD cards one by one.
ok, this is actually quite a good method and it is rather painless compared to installing and fighting with android studio/sdk/ndk etc...
More info about this can be found in the "Sharing your patches" section on the droidparty.net site.
thanks I didnt see that sorry
enrike
On 7/3/19 5:17 am, enrike wrote:> there are some issues I need to check yet
One thing that would make SyncJams more reliable is if I removed the elaborate state-sync feature. Alas I succumbed to the typical programmer scope-creep and tried to throw the whole kitchen sink into the protocol. What I should have done, and what I hope to work on in future, is to keep a very tight focus on clock sync. This would reduce the amount of traffic on the network to a single UDP packet per tick.
Cheers,
Chris.
we would like to do the following: on device joined send a message only to that device. is this possible?
also I feel we have experienced some weird fluctuations in the tick. is the Symcjams tick trying to be as accurate as possible? or it is more important to maintain a shared tick where all devices are in sync even if the tick becomes a bit irregular?
thanks
enrike
19/3/7 02:55(e)an, Chris McCormick igorleak idatzi zuen:
On 7/3/19 5:17 am, enrike wrote:> there are some issues I need to check yet
One thing that would make SyncJams more reliable is if I removed the elaborate state-sync feature. Alas I succumbed to the typical programmer scope-creep and tried to throw the whole kitchen sink into the protocol. What I should have done, and what I hope to work on in future, is to keep a very tight focus on clock sync. This would reduce the amount of traffic on the network to a single UDP packet per tick.
Cheers,
Chris.
we would like to do the following: on device joined send a message only to that device. is this possible?
I actually solved the problem I had by setting.getting a state, so no need to send messages individually. nice system btw.
also I feel we have experienced some weird fluctuations in the tick. is the Symcjams tick trying to be as accurate as possible? or it is more important to maintain a shared tick where all devices are in sync even if the tick becomes a bit irregular?
I just experienced this again. For some reason despite BMP was 60 the tick was twice faster, if not more, for a while, later it went down to 60. I dont know why this might be happening. It just happens sometimes. I think at some point it was the opposite, it went down to 30bpm or so.
thanks
enrike
On 10/3/19 5:05 pm, enrike wrote:
I just experienced this again. For some reason despite BMP was 60 the tick was twice faster, if not more, for a while, later it went down to 60. I dont know why this might be happening. It just happens sometimes. I think at some point it was the opposite, it went down to 30bpm or so.
Hi Enrike,
This sounds like a bug. If you can get me a patch that replicates it reliably I'll file an issue on GitHub.
Cheers,
Chris.
I just experienced this again. For some reason despite BMP was 60 the tick was twice faster, if not more, for a while, later it went down to 60. I dont know why this might be happening. It just happens sometimes. I think at some point it was the opposite, it went down to 30bpm or so.
Hi Enrike,
This sounds like a bug. If you can get me a patch that replicates it reliably I'll file an issue on GitHub.
I will try but its going to be difficult because it just happens very randomly and I dont see any pattern at all to guess where it might come from. Just in case it is an initialization issue with the BPM argument in the sync-jams object, I am passing a set-state /BPM 60 message on loadbang after a 1 sec delay. So far I have not seen it again but it pops very very randomly so it might be coming from anywhere else.
enrike
Hi Enrike,
On 11/3/19 4:48 pm, enrike wrote:
This sounds like a bug. If you can get me a patch that replicates it reliably I'll file an issue on GitHub.
I will try but its going to be difficult because it just happens very randomly and I dont see any pattern at all to guess where it might come from. Just in case it is an initialization issue with the BPM argument in the sync-jams object, I am passing a set-state /BPM 60 message on loadbang after a 1 sec delay. So far I have not seen it again but it pops very very randomly so it might be coming from anywhere else.
Do you have some evidence to point to this being the case? It would be good to know if there is a bug in the initialisation code.
Cheers,
Chris.
On 12/3/19 8:21 am, Chris McCormick wrote:
Hi Enrike,
On 11/3/19 4:48 pm, enrike wrote:
This sounds like a bug. If you can get me a patch that replicates it reliably I'll file an issue on GitHub.
I will try but its going to be difficult because it just happens very randomly and I dont see any pattern at all to guess where it might come from. Just in case it is an initialization issue with the BPM argument in the sync-jams object, I am passing a set-state /BPM 60 message on loadbang after a 1 sec delay. So far I have not seen it again but it pops very very randomly so it might be coming from anywhere else.
Do you have some evidence to point to this being the case? It would be good to know if there is a bug in the initialisation code.
What I mean is, are you specifically seeing the bug occur immediately after a new device joins?
Cheers,
Chris.
On 11/3/19 4:48 pm, enrike wrote:
This sounds like a bug. If you can get me a patch that replicates it reliably I'll file an issue on GitHub.
I will try but its going to be difficult because it just happens very randomly and I dont see any pattern at all to guess where it might come from. Just in case it is an initialization issue with the BPM argument in the sync-jams object, I am passing a set-state /BPM 60 message on loadbang after a 1 sec delay. So far I have not seen it again but it pops very very randomly so it might be coming from anywhere else.
Do you have some evidence to point to this being the case? It would be good to know if there is a bug in the initialisation code.
What I mean is, are you specifically seeing the bug occur immediately after a new device joins?
My "feeling" is that whenever it has happened, it has always been on start, when the devices joined for the first time. But it has been very random to get any solid evidence or see any pattern. We will continue doing tests so if I see anything I will report.
enrike
-
Antoine Rousseau -
Chris McCormick -
enrike