06-29-2024, 09:28 AM
Well, don't bash the old editor too hard. It offers a low entry level for a seldom programming experience. What I mean:
When you discover Phyphox some first thought is, wow, I can do something with the sensors, cool.
When you start developing your own experiment some dark thoughts arise, how could this be working at all?
What is the base frequency in which the experiment is being executed?
The location sensor is at about 1 Hz, the linear acceleration is at something above 200 Hz, and an independent append module is at something in-between.
A linear programming paradigm does not apply.
How could I develop anything at all in Phyphox?
I started developing my (first) experiment about 4 weeks ago.
And only 3 weeks ago I got some understanding of how I could do things, when I was thinking about analogue computers and how to program them.
With the visual editor you do not implement directly your algorithm as you do in the more common linear programming languages.
Instead you define bondary conditions for the data flow routes (modules, buffers, connections; notice that buffers themselves are also kind of a module with which you can encode some behavior). Just as you would design for an analogue computer the size of containers, the diameter of tubes, the resistence of a wire, etc. And instead of water or electrical current, sensor data is running through the experiment, with each data source having its own frequency. I think, it is more like some multi-frequency, parallel spreadsheet calculation than like a shell script.
For me it is a seldom opportunity to have this kind of programming experience.
And maybe this kind of programming experience is even more important in terms of didactics than "just" reading out some sensor data.
Sure, the sensor data is important if you want to use Phyphox for your physical experiments.
Maybe this unique programming experience is an equally important feature of your app and deserves some own article; which might already exist, I cannot tell. In the end, Phyphox is providing its own programming language for an event-driven real time environment, isn't it? Maybe this is not seen in the public as Phyphox' major feature. (Not sure about your Python statement. Better to not provide the opportunity of code injection to a mobile phone. Currently you have with your own programming language an encapsulated system in which only your rules apply, I would not allow experiments defined as Python or any other code.)
Only when I had that non-linear understanding of what I do in the editor, I was able to shortcut the modules (that evil "X" in the module connectins in my screenshots before) and could rip apart buffers and build them up again with each cycle, at whatever frequency the cycles would have, the frequency is no longer important. Hmm, sometimes I understand how this "X" works, but then there are also times when I'm no longer that sure how it could work at all. For sure it is not trivially working, and for sure it is only working when several of these modules are being executed in the correct order, not only the two modules connected with the "X", but others as well. Would be interested in your detailed explanation how this would really work.
I would have the hope that the new editor does not introduce limitations compared to the old editor, meaning that I could use the new editor to continue to edit experiments that I started to develop in the old one (that evil "X"). Sure, would be also nice if the new editor would offer some help for this "non-linear" programming style. Maybe also that the new editor could be completely independant from any module specific definition, in a way that it does not get outdated when you invent new modules. You could consider to have the module definitions independently from the editor implemention as some schema that you could separately provide and update any time when you come up with a new module or enhance an existing one.
My hope would be that the new editor could do the thing from my attachment without the need to change anything in the implementation of this experiment.
If you deprecate the old editor it would be still around and could be used in some legacy mode? Which more or less is already the current status quo, isn't?
Well, it is only my personal opinion and I do not claim to have understood it completely. Cheers
When you discover Phyphox some first thought is, wow, I can do something with the sensors, cool.
When you start developing your own experiment some dark thoughts arise, how could this be working at all?
What is the base frequency in which the experiment is being executed?
The location sensor is at about 1 Hz, the linear acceleration is at something above 200 Hz, and an independent append module is at something in-between.
A linear programming paradigm does not apply.
How could I develop anything at all in Phyphox?
I started developing my (first) experiment about 4 weeks ago.
And only 3 weeks ago I got some understanding of how I could do things, when I was thinking about analogue computers and how to program them.
With the visual editor you do not implement directly your algorithm as you do in the more common linear programming languages.
Instead you define bondary conditions for the data flow routes (modules, buffers, connections; notice that buffers themselves are also kind of a module with which you can encode some behavior). Just as you would design for an analogue computer the size of containers, the diameter of tubes, the resistence of a wire, etc. And instead of water or electrical current, sensor data is running through the experiment, with each data source having its own frequency. I think, it is more like some multi-frequency, parallel spreadsheet calculation than like a shell script.
For me it is a seldom opportunity to have this kind of programming experience.
And maybe this kind of programming experience is even more important in terms of didactics than "just" reading out some sensor data.
Sure, the sensor data is important if you want to use Phyphox for your physical experiments.
Maybe this unique programming experience is an equally important feature of your app and deserves some own article; which might already exist, I cannot tell. In the end, Phyphox is providing its own programming language for an event-driven real time environment, isn't it? Maybe this is not seen in the public as Phyphox' major feature. (Not sure about your Python statement. Better to not provide the opportunity of code injection to a mobile phone. Currently you have with your own programming language an encapsulated system in which only your rules apply, I would not allow experiments defined as Python or any other code.)
Only when I had that non-linear understanding of what I do in the editor, I was able to shortcut the modules (that evil "X" in the module connectins in my screenshots before) and could rip apart buffers and build them up again with each cycle, at whatever frequency the cycles would have, the frequency is no longer important. Hmm, sometimes I understand how this "X" works, but then there are also times when I'm no longer that sure how it could work at all. For sure it is not trivially working, and for sure it is only working when several of these modules are being executed in the correct order, not only the two modules connected with the "X", but others as well. Would be interested in your detailed explanation how this would really work.
I would have the hope that the new editor does not introduce limitations compared to the old editor, meaning that I could use the new editor to continue to edit experiments that I started to develop in the old one (that evil "X"). Sure, would be also nice if the new editor would offer some help for this "non-linear" programming style. Maybe also that the new editor could be completely independant from any module specific definition, in a way that it does not get outdated when you invent new modules. You could consider to have the module definitions independently from the editor implemention as some schema that you could separately provide and update any time when you come up with a new module or enhance an existing one.
My hope would be that the new editor could do the thing from my attachment without the need to change anything in the implementation of this experiment.
If you deprecate the old editor it would be still around and could be used in some legacy mode? Which more or less is already the current status quo, isn't?
Well, it is only my personal opinion and I do not claim to have understood it completely. Cheers