09-23-2018, 02:27 PM (This post was last modified: 09-23-2018, 07:35 PM by Patrick.)
Hi,
I want to modify the experiment "Audio Scope" (german: "Audio Oszilloskop"). My aim is to develop an own version of this experiment for a more student-friendly usage in school (perhaps this experiment will be part of my final exam at university). Therefore I want the graph to be at a fixed position with a fixed size.
In the standard experiment the y-axis gets refreshed (because of the trigger?), and with each refresh the values at the axis disappear causing the whole graph to increase in size (because of the aspect ratio of 2.5). After the new data is cashed/calculated, the axis get new values and the whole graph gets shrunken again, because there is less screen space for the graph. This is causing a really unsteady image and is confusing, especially in longer experiments.
Is there an option, to fix the graph in the top right corner with an graph-width of e.g. 80% of screen space? So that the values of the y axis can change, but won't influence the size of the graph.
I am not entirely sure if I understood the question correctly, because phyphox has both, options for axis ranges and aspect ratios, but they apply to different things. The aspect ratio has nothing to do with the scaling of the data but with what area on the screen is used by the graph. It is the ratio of the width of the image to the height of the image, no matter if it is showing valus from 0 to 1 or from -42 to 23. (This option is far from perfect and we are thinking of adding options to auto-fill the screen in the future.)
I think what you are looking for are the options minY, maxY, scaleMinY and scaleMaxY. The latter two can be set to "auto", "extend" and "fixed". "auto" and "extend" both rescale the graph to fit all data and for the audio scope, it is specifically set to "extend", which only "zooms out", but never zooms back in if the new data set has smaller values. What you want to do is scaleMinY="fixed" and scaleMaxY="fixed". If these are set, you can set minY and maxY to numbers which determine the range of the y axis.
However, there is one problem, which is why we did not elect to use a fixed range here. All the phones have different mics, amplifier circuits and maybe even different ways to filter the sound in software. The audio data is represented by samples between -1 and +1, but the exact scaling can vary a lot. So, if you set a fixed range that shows the audio of a normal voice nice on one phone, it could be too small or too large on another. For example, a loud noise shows up on my Nexus 5X at an amplitude of about 0.8, but on an iPhone 6s it only has an amplitude of 0.1.
Unless you are adapting this experiment for a specific phone to measure a specific sound, you should consider to add an edit box to enter a scaling factor. Or maybe, you will be more happy with the upcoming version 1.1.0 (which you can try here: https://phyphox.org/forums/showthread.php?tid=12). It allows zooming the graph and then keeping the selected zoom level.
09-23-2018, 07:22 PM (This post was last modified: 09-23-2018, 07:40 PM by Patrick.)
Hi Sebastian,
thanks for your fast answer, but I do not mean the axis ranges (minY,...) or the zoom in the data. I really mean the screen area, that is used by the graph. I'm aware of the fact, that different phones will show the data in another way.
The only option for displaying the graph in the editor ist the aspect ratio (e.g. 2.5). That means, that the width of the borders of the graph are 2.5 times of the height of the borders. That means, if there are values on the y-axis, the border of the graph begins right of it. But while buffering and calculating, the values at the axis (and therefore the length of the used place by it) change, especially when it shows no values on the axis while refreshing the image. When there are no values at the axis, the left border of the graph goes as far to the left, as it can (right beside the axis name). When new data is calculated, it springs back to the first position. This causes a continuously changing of the size of the frame of the graph.
So it would be perfect, if one could say, that the total width of the graph is e.g. 80% of the screen width and the whole graph is fixed in the top right corner. So the values of the y-axis could change, without causing the changes of the actual screen area taken by the graph.
I try to add some pictures in my original post, perhaps they help to understand my problem. Unfortunately I am not able to upload a video of the screen capture of the iPad.
Perhaps you can also contact me per PM in german, this might be easier.
Oh, sorry, I really misunderstood you there. I just checked and realized that this is a problem I was not aware of. This seems to be a bug, which only occurs on iOS, which is why I did not notice it earlier. (I am wondering if no one mentioned it before or if it was at a moment I could not write it down - the bug is rather obvious).
However, clearing the buffer is not exactly the problem, but only the part that makes it visible. I have not yet found the root of this bug, but it seems like the iOS version sometimes starts the calculations without new data and then deletes the old data anyway. I suspect that either the logic, which should set a minimum delay between subsequent calculations is broken, or that the minimum buffer size (and hence the minimum calculation interval) is not low enough on iOS.
Anyway, I will see to it for the next version (either 1.1.0 or 1.0.14 if a language update happens before 1.1.0). Until then, you can avoid this problem by sticking to slightly longer intervals ("Dauer"). I just tried on an iPhone 6s, where anything from 30ms upwards seemed just fine.
Do you know, when the next version will come out approximately? If you need more volunteers to do the closed beta test, I would be pleased to take part.
The "trick" with longer intervals also works on the iPad Air 2. Thanks for the work around, this might help with my further investigation until the update with the fix arrives :-)
I have become careful about estimated release dates. Some of the features in 1.1.0 should originally have been released in summer - last year. Also, I am once again behind schedule as I wanted to release all the documentation for the Android beta version by now.
Still, I hope that 1.1.0 will be released in October (well, near the end of it). There might be a version 1.0.14 in a few weeks however. This depends on the feedback of our Japanese, Taiwanese (trad. Chinese) and Portuguese translators. Those have finished their translations and I have sent them a test version to verify their work. Depending how fast I get a thumbs up from them, this 1.0.14 will be released before 1.1.0 and I can slip in the fix there.
