Is there a development environment to run/test/develop ETC patches on a mac? (Sometimes I don’t have the ETC with me.)
no but you could create one, basically its pygame, plus a few python modules…
I got it running on my Linux Ubuntu box pretty easily after doing OTC.
(I didn’t want to put it on the mac, as Ive other python dependent software running, that I didn’t want to interfere with)
sorry i don’t have time to detail the ins and outs (as id also have to test it to be happy to publish anything) … but if you look at my OTC package for the Organelle, that will give you most of the information you need to know
pygame on raspi/linux is really straightforward. I have it on both as i prepare for my dive into pygame.
i am going to start with a particle system and next month i am getting an ETC!!
Anyone familiar with WING? https://wingware.com/
OK, I have Pygame installed on my mac and was able to successfully run the “aliens” game. Now, how do I go about testing/running a mode for the ETC?
i am interested in this as well
I ran several pygame examples on my mac and my raspberry but i need to get comfy on pygame
I have used python alot for Pymol a research tool i use din grad school and PyBeat but i need to get a working environment too
I’ll share here as we develop this for users
Maybe @oweno will send my ETC early! haha
I got python/pygame installed with the instructions here: https://www.youtube.com/watch?v=L0Cl4Crg7FE
ok, if you have that running, then the best thing to do , is grab OTC_Mother, which is just the python side of the ETC. look at the run script, and you will see how to specify where the modes are
next your issue is , how do i control it? i.e. buttons/knobs.
what i do , and another reason to use OTC_Mother, is to use OscProxy, this way i can use my Organelle to control the ETC mode running on another machine.
… of course you could also use a midi controller, that may need a bit of hacking… or at least checking the manual/source code, to see what the relevant midi is… or if all buttons are supported.
this should be enough for a hack it yourself endeavour…
Does it matter whether I use the python version on the ETC (which is 2.2.7. as far as I remember), or can I use the latest python version (3.6.something). Same with the pygame version.
I think the usual methods for the ETC are that rudimentary, that there shouldn’t be any difference. But maybe in handling images (movies?).
EDIT: ok I can answer myself: appearently python3 has different synthax
print"bla" works in V2, but in V3 it must be
So you need python2
And just another experience: it seems to be useless to try it on Windows, because the ETC uses the module liblo / open sound control, which is as Posix (aka Unixoids) standard…
you can do posix stuff on windows, but for sure its a pain… probably as easy to have a Linux vm.
pygame, same version or keep an eye out for api changes.
as with all cross-platform dev, test regularly, there are always quirks on different platforms - and they are easier to spot early on.
honestly, though, if this is just for modes, i don’t think your going to hit many issues, as you say its all pretty rudimentary.
I think I’m actually going to setup my mac as well now, so that i can use it for grabbing etc visuals… so i don’t have to go any buy a video capture device
Only my local workstation is Windows. I have enough Linux machines here around (to be honest a complete Datacenter… ) so no trouble in this regard.
I pick up this thread again: I finally got an old laptop, installed Arch Linux and python with the modules listed in the ETCs python, and got the ETC_Mother running.
I added this to the main.py (the lines after the “while 1:”) to have a minimal control:
while 1: # new keyboard-control for event in pygame.event.get(): if event.type == pygame.KEYDOWN: if event.key == pygame.K_LEFT: etc.prev_mode() if event.key == pygame.K_RIGHT: etc.next_mode() if event.key == pygame.K_ESCAPE: sys.exit() if event.key == pygame.K_COMMA: etc.update_trig_button(1) if event.key == pygame.K_PERIOD: etc.update_trig_button(0) if event.key == pygame.K_o: etc.set_osd(False) if event.key == pygame.K_p: etc.set_osd(True) # end of new keyboard-control # check for OSC osc.recv()
so far so good.
But some modes which use audio seem to use only 56 of the audio events instead of 100. See here an example with S_Classic_Horizontal:
(the pic is mirrored, because I took it with “Photobooth” on my Mac).
Any idea, why I don’t get all audio events?
I managed to fix this issue on first hand by setting the inputrate in ./ETC_Mother/sound.py to 12000Hz
inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE,alsaaudio.PCM_NONBLOCK) [...] inp.setrate(12000) [...]
But still I do not understand it completely. It looks like the audiosetting on the Linux level is different between my computer and the ETC.
m trying to run ETC on RPi and managed to get Mother running and load first mode. However, only one frame of the mode is drawn and then Mother get stuck inside sound.recv() and im trying to find out why.
ll try to describe how I understand ETCs sound processing part, but maybe I`m completely wrong.
First of all, it sets sound card for capture with following parameters :
rate : 8000 Hz
channels : 1
format : PCM_FORMAT_S16_LE (2 bytes per frame = 16bits)
On sound.recv() data from buffer is read to length,data tuple (l,data) then it calculates moving average on three samples window, does the audio triggering, checks for trigger button and fills etc.audio_in[i] with moving average of received samples or with sinewave values, in case the trigger button was used.
I do not know if i understand reading operation in ALSA correctly, but i think that number of frames(samples) you can get is anything between 0 and periodsize in non_blocking mode. And zero length of received data is used to escape from “while l:” loop, because reading from sound card is done again at the the end of the while loop. When no frames for calculation are received then it ends.
I do not quite understand how it is possible that ETC`s sound card delivers enough samples during one video frame. In 30ms (video frame length) sound card fills the buffer with 240frames, if it is really running at 8kHz, so only 80 (240/3) values would be updated in audio_in.
Maybe it is running on 11025Hz (closest common framerate). Then first read would return 300frames and 2nd read would return 30frames. If I understand it correctly (and maybe not) it is critical for how long it takes for i in range(0,100) loop to finish. If during this loop new frames appear in sound card buffer, 2nd read returns l>0 and while l: loop never ends.
I think framerate, periodsize, moving average window length have to be tuned to match your soundcard capabilities (and CPU processing power) to correctly display sound which happend during last 30ms in 100 values.