• dom1817

    Take a look at Ofelia, it's a library based on OpenFrameworks for Pd available on Deken. The library has a lot of useful methods for procedural generation of shapes and you can also write your own scripts. It takes a little time to get into it but then you have basically endless possibilities.

    posted in pixel# read more
  • dom1817

    You can try the [savestate] object in Vanilla which stores lists of floats in the patch file.

    posted in technical issues read more
  • dom1817

    I think a good way to do it would be to use [list fromsymbol] which outputs a list of the corresponding ASCII characters. Then you need to see where the slashes are (ASCII 47) and split the list to get only the part after the last slash. A bit tricky but it should work.

    posted in technical issues read more
  • dom1817

    Hi @juliandp, can you explain a bit more in depth what you are trying to do?

    I think you need to decide which color space you want to use for the image sonification. The HSV or HSL color space (hue, saturation, luminance) might be useful if you want to make a different sound for each color range of the spectrum and also has a separate value for the brightness.

    posted in technical issues read more
  • dom1817

    Thank you, I somehow didn't notice the [array max] object in the [array] help file.

    I did a little research on the Pd list tonight and actually using a [log~] object with appropriate scaling is a good solution. Still not perfect but much better than before, will upload an updated patch soon.

    posted in technical issues read more
  • dom1817

    I've been trying to normalize the magnitude results of a FFT signal analysis in a range between 0 and 1.

    What I'm doing now is to do list operations on the tables to find the maximum value of the current FFT results and divide all the values by it (see patch attached). This works nicely with Pd generated waves, but it doesn't look good with samples (it's very narrow on the lower frequencies and not spread at all, see picture below).

    Here are my questions:

    1. Is there a way to normalize the values on the signal domain, without these table operations?
    2. If not, why does the normalized FFT looks so narrow?

    Many thanks!

    fft_normalization.pd

    fft_normalization.jpg

    posted in technical issues read more
  • dom1817

    Cool, I'm happy that it works! I think the «waveform» row, as intended by ShaderToy, is a simple [tabwrite~] of the signal samples with no FFT analysis.

    I'm familiar with the audio distortion problem in Pd + Gem. There are two options I'm aware of. The first one is to set an higher latency in Audio preferences (something around 25 should work). The other way is to run two instances of Pd, one for audio and the other for video. The two can communicate using [netsend] or something similar. This works even with very complex patches but it's a bit tricky, maybe there are better ways to do it.

    posted in technical issues read more
  • dom1817

    I think this could be one approach:

    1. Make a PD table with the results of the FFT (see example in 3.audio.examples/I02.Hann.window)
    2. Make a LUA script with Ofelia to convert a PD table into an image. The image should be 1 by [size of PD table] pixels, each pixel should have a normalized gray value representing the amplitude for each frequency.
    3. Make a FBO of that image and use it as a texture in your shader.

    Step 1 and 3 seems pretty straightforward. Step 2 should be doable but requires a bit of LUA scripting skills (which I don't have).

    posted in technical issues read more
  • dom1817

    Hi @Jona, I couldn't find it either because I was running Deken on a 32bit Pd (for GEM compatibility). I didn't notice at first that Ofelia 2.0 only runs on 64bit.

    posted in news read more
  • dom1817

    What about the new [savestate] object in Pd 0.49? I think it does exactly that. You get a bang on the left outlet when the patch is saved and a bang on the right outlet when the patch is loaded.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!