onirom

did a small raw binary-like implementation of an extended (base-16) version : https://www.onirom.fr/wiki/snippets/#JavaScript_:_Extended_C...

doesn't need to be accurate, could do something like this (distance + treshold) :

https://susam.net/fxyt.html#XN128dXN128dpYN128dYN128dpsN4096...

smaller with dup :

https://susam.net/fxyt.html#XN128dDpYN128dDpsN4096lN255pC

circles pattern : https://susam.net/fxyt.html#XDpYDpsN8qN3riN255pC

PS: fun tool !

Somewhat related but this can go pretty low in amount of code (and data) with a bit of design, here is some experiments and details on the generation of monospace blocky font with very low amount of data (data is encoded into bitfield) and how to style it through simple operators or algorithms such as diffusion curves, the aim was slightly different as it focus on using smallest amount of CPU instructions : https://www.onirom.fr/wiki/blog/25-09-2022_tiny_bitfield_bas...

Is there some tools like this which can simulate old school stuff such as magnetic core memory ?

There is Photosounder which have excellent sound quality (all edit is in frequency domain and it then convert back)

For free there is also Virtual ANS and https://www.fsynth.com on the more experimental side (conversion is done raw using additive synthesis, phase information is lost so sound quality is affected)

Are you on Linux ? There is a known issue on Linux with the server running in background when you launch the AppImage directly (by clicking on it) so it is actually launched but you can't see it and if you launch it a second time it will fail to listen because the port is already busy with the first one, the AppImage must be launched in a terminal.

Guess this is not restricted to interface design for example having quit & save keys shortcut close together...

A VSTi i have used several times for birds & animals is "sounds of nature" by Xoxos, maybe you could take a look at how it is done, my guess is some fast FM modulations.

To stay in topic i have synthesized some nature sounds (birds, waters) myself using this synthesizer and a simple two oscillators FM setup with massive pitch modulations for each oscillators, you can hear it on :

https://youtu.be/25o4Ru8kbpE?t=1111

And FM squeaking doors : https://youtu.be/25o4Ru8kbpE?t=1404

So my guess is that some FM with pitch modulation and many oscillators may be the way to go.

Percussion can be synthesized with convincing results through resonant models (simple resonant filters with initial noise), this is called modal synthesis, you can find filters parameters for some real instruments here : http://www.csounds.com/manual/html/MiscModalFreq.html

The sound server itself (the link) is 100% CPU and does not use the GPU at all. One of the client application however (your description) output RGBA data generated by the GPU.

I don't know if that was a good idea considering there is a soldering problem on the Nexus 5X which shorten its lifetime to around 2 years, CPUs just fail after some times. I preferred to take a Android One device since then, cheaper while being similar in speed. (Phones such as Nokia 6.1 and so on) but the Pixel 3a is nonetheless cool, hope it will don't have conception issues!

Built mine some days ago with a custom "portfolio generator" :

https://www.onirom.fr

Yes, this is actually how it work however page flipping mechanism require a memcpy, as such it is as effective as not using page flipping and just memcpy a front buffer to display and doing software flipping through pointers exchange, the only advantage of using page flipping is that it require much less operations and prevent tearing but performance wise, it is roughly the same.

Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.

Did a simple clearing test with a 4 cores Raspberry PI 3B and 1280x768 resolution, i get 30 FPS.

However a single core memset (still RPI 3B) for this case is fast : 235 FPS

The time goes into calculating a fullscreen pixels-based effect (so yeah; buffer contents), the point of this library is not the FB implementation which is a simple / bare-metal one.

The point is to render graphics content in a consistent way across multiple CPU cores but still remain lightweight enough to be used with your own implementation, this might change but that was the initial goal.

I am aware of those, this might land in a future update.

The library initial focus was just to get multiple cores to work for graphics task...

A late night mistake that is mostly fixed. (and there are some other typo errors as well, will check it later on)

Thank you!