This is so beautiful! Thank you all!!!
great to see you having fun with it @chrisk
So glad to see people enjoying this! @thetechnobear did all the heavy lifting.
You’re awesome! Thanks for making this! <3
@thetechnobear if I’m running this on the Organelle OTC. What would the folder setup look like?
Would it look like this?
Also, if I’m looking to use the 320 set as well as the 640 set. Will I place both of them into the SpinningDiscs folder?
should just be
but if you download from patchstorage, unzip and put in your modes directory, it should just work
the just add stuff to the images folder you find there.
you just needs to put them in the images directory
bare in mind, with OTC/ETC all images (for all modes) are loaded into memory, so memory can get short if you start adding lots of images … also the bigger the images the slower the frame rate.
so its a trade-off, depends on what you want etc.
what id recommend is trying them , and then keeping the ones you like the most.
hmm, looks like there isn’t a specific way to stream from disk, you still have to load it into a variable, but the difference would be instead of loading many images into an array in the setup() section of the mode, it could just load them as it needed in draw() :
img = pygame.image.load('first-image.png') screen.blit(img,(0,0)) # replace img with new image img = pygame.image.load('second-image.png') screen.blit(img,(100,100))
so this would draw 2 images on the screen, but only require memory for one.
err, that is not what id call ‘best practice’ , rather a ‘trade-off’
the issue is, if you call load in render, then its very likely your display will stutter when you switch images (especially if its a large image) - so when are you willing to accept this? I doubt you would in a live set.
the only way to handle this better, would be to load images in a background thread, but I doubt this will help much considering the ETC/Organelle are single core (and python is notoriously bad with thread synchronisation)
so yeah the choice is, do you want your modes to be stutter free or have lots of them?
for me, this is an area I’ve considered improving on OTC…
I think the UI should support a concept of a ‘performance’ (or scenes?),
such that you can have lots of modes on the disk, but you only load up a subset of them for performance.
this way you can optimise the resources for a live set , but you can have loads of modes on the disk for when your designing you ‘set’
this concept could be extended to images, so that you ‘tag’ which images you want to have in the set.
this is really just a organisation function, which you can do manually, buts its really quite painful.
yepp, that is the right approach.
I could imagine to have the ODS button like a “Shift”-key.
Now: how do we recognize double keypresses like “ODS”+“next-Scene”. I don’t think, that the pygame.K_-Function can react on two keys pressed at the same time…