• 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
  • dom1817

    Is there a way to dynamically set the name of a [receive] object using Pd vanilla? It's a bit weird that [send], when created without arguments, has a second inlet to do this, but [receive] doesn't.

    posted in technical issues read more
  • dom1817

    I came up with a clean solution based on your suggestions.
    Thanks a lot for the heads up!

    posted in technical issues read more
  • dom1817

    Native recording using GEM is not ideal in my experience. I think a good way to do it is using [syphon]. You can download the external for Pd then route the video to Syphon Recorder. Not exactly simple but it works.

    posted in technical issues read more
  • dom1817

    @weightless thanks. This is a solution but to make my patch a bit less complicated I wanted to send a message directly to the GUI object and get its value back. Probably it's just not possible this way.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!