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.
pygame_cffi - uses cffi to get C implmention, useful with pypy
ditch pygame, and just go to sdl2 with python/pypy?
Ive looked at each for these in turn and all seem useful, but its really unclear which are stable , and which are just ‘development projects’ that might never come out of beta
going further a field… goals/requirements
this graphics programming is a bit of fun for me, so I don’t want to have to spend hours writing and debugging a single mode.
it has to some how support audio input
has to be much better performance that pygame/python - otherwise on real reason to switch
needs to run full screen
use any available hardware acceleration (preferably, without coding ;))
I suspect it needs either to be generative native code, or using JIT , to get performance we need.
options
C++ and a gaming engine…
something like unity?
Id have to invest some time working out what can be used that is high level that ‘productivity’ is maximised.
Java (possibly with an game engine?)
allows dynamic loading, easy to code, not sure about its graphics performance
Processing
not sure on its performance, or compatibility
pure data, nope , not efficient enough.
are there any other options to consider?
if it runs on a raspberry PI, then this might give an indication its possible on the ETC/Organelle.
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
various
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
)
