04-17-2020, 11:24 AM (This post was last modified: 04-17-2020, 11:57 AM by fbouquet.)
Hello,
I am experimenting with the phyphox file format to create new experiments. So far I am playing with toy experiments to understand how phyphox is working. I have a question, which I think is for Sebastian (Hello!):
I created a size 1 buffer which I initialized to 0, and I visualize its value in a <view> <value>. At the beginning, even before I hit the "start" button, it shows 1 instead of "0", and I wonder why. In the <analysis> section I increase the value of this buffer each second when the program is running, so I guess there is a first pass at the analysis section even before the program runs? What did I miss?
I attached here a minimal program demonstrating this effect.
Thank you in advance for any help,
Cheers,
Fred
Playing a bit more :
I have the impression that phyphox executes once the analysis section when the experiment is open, but then rests at the end of the analysis section. When the user hits the "start" button, it continues the execution from the experiment starting form here (the end of the first analysis). When the "pause" button is punched, the analysis is performed, and the program rests at the end of the analysis section. When "restart" is punched, the program restarts from here (the end of the analysis, not the beginning).
Is that correct?
I am playing with the dynamic sleep option, and I was trying to understand how the program works, by switching analysis section of 3 and 10 seconds (minimal program attached).
(04-17-2020, 11:24 AM)fbouquet Wrote: I created a size 1 buffer which I initialized to 0, and I visualize its value in a <view> <value>. At the beginning, even before I hit the "start" button, it shows 1 instead of "0", and I wonder why. In the <analysis> section I increase the value of this buffer each second when the program is running, so I guess there is a first pass at the analysis section even before the program runs? What did I miss?
I have tried to reproduce this (test_analysis.phyphox, iOS and iPadOS 13.4.1), however, it appears that I get the expected result:
on entering the experiment it displays “Index: 0,00”,
on start it increments by 1,00 each second,
on stop it keeps the value,
on restart it continues incrementing by 1,00 each second.
The only thing that does not look quite right is that the current value is still displayed if I delete the data. Nevertheless, on start the first value after one second is 1,00. Leaving and reentering the experiment fully resets the data, i.e. back to “Index: 0,00”…
Could you please post your PhyPhoX and Android versions.
(04-17-2020, 04:02 PM)Jens Noritzsch Wrote: I have tried to reproduce this (test_analysis.phyphox, iOS and iPadOS 13.4.1), however, it appears that I get the expected result:
on entering the experiment it displays “Index: 0,00”,
on start it increments by 1,00 each second,
on stop it keeps the value,
on restart it continues incrementing by 1,00 each second.
The only thing that does not look quite right is that the current value is still displayed if I delete the data. Nevertheless, on start the first value after one second is 1,00. Leaving and reentering the experiment fully resets the data, i.e. back to “Index: 0,00”…
Could you please post your PhyPhoX and Android versions.
Thank you for testing!
I am running phyphox 1.1.5 (file format 1.9) on an android 8.1.0
running the experiment test_analysis.phyphox that is posted above, I have:
on entering the experiment it displays "index: 1.00"
on start it jumps to 2 instantaneously, then increments by 1 each second,
on stop it keeps the value,
on restart it jumps to the next value instantaneously, then increments by 1 each second
on deleting the data, the index value is briefly shown at 0 then it jumps at 1. When restarting the experiment, it jumps at 2, then increments by 1 each second
To be sure that I was using exactly the same program than you, I downloaded the version from the forum before doing the above tests.
To verify that the "jump instantaneously" was not an error of my sense, I changed the running time of the analysis section from 1 to 3 second, and everything I wrote above is still valid, except that the increment time is now 3 s of course. (program attached, same name).
I am afraid, that the start-up behavior is not identical across Android and iOS. Both version are implemented separately and indeed, the Android version runs an entire iteration to be able to show some initial data like for example the sound wave of the tone generator. However, the student who initially ported the very first phyphox version to iOS tried to be a bit more efficient about it and implemented some logic to figure out which buffers needs to be calculated. At some point this has been removed again, but both version never worked identical in this regard, sorry
Jumps on continuation happen because we do not simply count up with subsequent new values, but we get a timestamp relative to the last boot of the phone. We then subtract the beginning of the measurement. However, if you pause and then continue, you usually do not want a long gap with the duration of the pause, so we use the current time axis (if there is any) to adjust the reference point. But since we cannot know the exact time interval between data points, there is actually no gap there.
(Sorry, this is a rather quick answer, since I have to call it a day and cook for my family )
I explored in more detailed the difference between iOS and Android. Not for the fun of it, but because I wanted to be able to detect the first run of an analysis sequence. [It was for the program that I posted in the acoustic resonance program thread - I needed to skip the first analysis run since no audio data are available then].
Here is what I did, and that works, but is a bit dirty:
- I create an index that is initialized to zero in the declaration section, and upgraded by one each analysis run ;
- I used a timer to store the elapsed time in the analysis section
- the analysis section is performed once each second (I am working with sound and need to let some time between each analysis run)
Now, the index does not tell the same number during the first analysis run on iOS (1) and Android (2) as Sebastian told us above, but the timer also behaves differently. The program below demonstrates it. When the program is open, it shows (first run will be explained later):
On iOS : time = 0s, index=0, first run = 0
On Android : time = 0s, index=1, first run = 1
When the program is run, at the first run, it gives
On iOS : time = 1.02s, index=1, first run = 1
On Android : time = 0s, index=2, first run = 1
On the second run it gives :
On iOS : time = 2.04s, index=2, first run = 0
On Android : time = 1.01s, index=3, first run = 0
On the following run, time and index increase by 1 each run, as expected. First run remains 0 (see below).
So comparing both OS, the timer is off by 1 run, and the index is off by 1 run in the other way. To detect the first run, what I did is to add the time and index, and to give the value 1 to the variable first_run if the total is less than 3, and 0 if the total is more than 3. It works (first run is equal to 1 during the first run and 0 the others), but it is a bit dirty, and note that it is already 1 before the program is run on Android platform.
I was able to make it work for my needs, but is there a better way to detect the first run on an experiment? i am curious...
I am still rather new to phyphox editor so please apologize if this cannot work: would it be possible to match the index against time in the first two steps, i.e., set index to 0 for time=0 and set index to 1 for time close to the increment?
Ok, that is confusing me too. I have to look into this and make it a more consistent. The way we adjust the timers (as everything is given as time since start of the system) is rather convoluted as we need to estimate a reference time if a measurement is continued. I do not have a properly explanation right now.
However, I was wondering why this problem never bothered me with the other experiments and I think that you should not try to detect the first cycle, but try to detect if the audio buffer has been filled. So, you would use the "count"-Module and use its result to only write the results to the big result-buffer if there are enough values in there to give a reasonable result.
04-27-2020, 03:58 PM (This post was last modified: 04-27-2020, 04:14 PM by fbouquet.)
Thank you for having a look at my problem!
Unfortunately the trick of using the number of data point in the audio_in buffer does not work... On iOS, there is a one second delay when the experiment is run, which let the audio_in buffer be filled to the max even though it is only the first run. If you run the attached program, you will see this effect (on the frist run, size_audio_in is already 48000). On Android, it tells me that the audio_in is filled at 4800 points, which is exactly 10%, or a 100ms delay, which I do not really understand, but any way, we are facing the problem of the difference in which the timer is set between the two OS. [this last sentence is too long and I am afraid not 100% english, I hope I am clear enough]
It is the first time that this problem is seen I guess because 99% of the time you do your experiment in one go. Here, you create the frequency in one go, and you analyse the results in the following analysis. Note that the Walnut experiment you created add the same mechanism, but since the starting frequency was set and could not be changed, it gave a way to test this. Maybe I should have a second look to this experiment and see whether it could be modified.
Anyway, since you plan to change the way the audio is handled, it is not a big problem for me, it is more of an academic interest (and a clear sign that I should test my experiments on both OS !), do not spent too much time on that problem. If you have an easy way to detect a first pass I will be happy, but if not my hack is working so I am happy nevertheless.
Cheers,
Fred
(04-27-2020, 09:54 AM)Jens Noritzsch Wrote: I am still rather new to phyphox editor so please apologize if this cannot work: would it be possible to match the index against time in the first two steps, i.e., set index to 0 for time=0 and set index to 1 for time close to the increment?
Hello!
Well I guess you could, but you would have to tinker a bit the algorithm for it to work on both iOS and Android. But as soon as you use both the time and the index you will end up with a solution which will be more or less mathematically equivalent to the one I implemented, the sum of both timer and index smaller than 3. It may be more elegant, but it won't really answer the problem I think, don't you agree?
(As noted above, this is more an academic interest for me; I would be glad if a solution is found, and I appreciate your help, but I have a working solution and it is not worth too much of your time).
Cheers,
Fred
(04-27-2020, 03:58 PM)fbouquet Wrote: Note that the Walnut experiment you created add the same mechanism, but since the starting frequency was set and could not be changed, it gave a way to test this. Maybe I should have a second look to this experiment and see whether it could be modified.
Well, actually I had a second look at the Walnut experiment, and I am pretty sure that there is a problem in the way the frequency are handled. At least on Android, I think that the first measurement is not correct, because of the problems discussed here. Again, not a big deal, but the solution will not be found there.
