ok, I’ll put this out here, as Ive been doing a bit of research, but interested if others have any solid ideas.
python+pygame is great, its easy to program … and wont crash and burn if you type in bad code (like C++ )
important note given the above, the rest is about ‘other options’ for some people, i think python/pygame is great for ease of use/majority.
BUT, its not the most efficient… which on a platform with limited resources is pretty important, and also for some reason (which im not 100% clear on) , doesn’t seem to have much hardware acceleration.
why? change? what am i after?
well I want to free up some cpu, so as to get more available for audio processing e.g. more sample, ffts so we can do frequency effect changes.
one option is simply re-evaluating how to use pygame e.g. for some use cases, using sprites and minimising redraw area could bring huge improvements.
I would take a look at openFrameworks, I think you would like it. It is similar to Processing, but in C++. It has many fun features like audio and OSC and a huge active community. It requires opengl or opengl ES at least, however. very fun to run on raspberry Pi, but haven’t been able to run it yet on Organelle / ETC. It should be possible as the iMX6 processor does have the vivante gpu that can do opengl ES…
The main problem I can see is that the GPU based OpenGL ES on the organelle is broken, as far as I can see anyway, I think this is a kernel problem. The software based MESA OpenGL ES does work but is a little on the slow side!
Getting the GPU going on the organelle would definitely save a fair bit of cpu, from what I know of pygame it just uses the frame buffer which has to be pretty cpu intensive. There is an OpenGL version of pygame I think so if the gpu issue was sorted maybe this would be a way forward?
from my experimentation, I suspect the same too… this is why i was looking for something with more performance to use what remaining cpu we have.
( i could use other cores, but then others wont be able to reuse my patches/modes)
if this was fixed, sure pygame opengl (or even plain pygame) will perform better, but its still far from perfect, especially if you want to start doing audio processing…
(current etc/otc is copying at low resolution, 300 mono samples at 8k sample rate, fine for general volume but a bit low for frequency analysis)
hmm, i guess all comes down to where i spend my effort - unusually (in S. Spain) . today its snowing outside, so perhaps I’ll play with some ideas later
cinder vs openframeworks , both look interesting, each seem to have their advocates.
i might look at the dependency list, the one with the least dependencies may be the easier one to get build on the organelle
I even tried with with the one that is supposed to be currently used… (see my other thread for details)
the issue is i didnt get far with any of them, as basically they dont seem to recognise the sdcard - this is ‘expected’ (if you read the release notes) as its changed to a different device number, but even changing that didnt help… ( even by rebuilding uboot etc)
so basically, it does the initial u-boot bootstrap, starts loading (off the sdcard!) , and then when it comes to mount the rootfs off the sdcard it fails.
I will say, last time i was trying i didn’t have an hdmi monitor close to hand, and going back and forth to a tv to check the console logs got boring pretty fast … I now have put an hdmi screen next to my mac in my studio, so i should probably give it another go…
anyway, we should probably discuss this back on the kernel hacking thread… as thats where most of the info is