• dom1817

    Hi everyone,

    I've seen a message on the list about a user who is not able to register to the forum:
    https://lists.puredata.info/pipermail/pd-list/2019-11/126253.html

    Can one of the admins have a look into it?

    posted in this forum read more
  • dom1817

    @AllesDings I think you could do something like this in Ofelia:

    local img = ofImage()
    img:grabScreen(0, 0 , ofGetWidth(), ofGetHeight())
    img:save("screenshot.png")
    

    posted in pixel# read more
  • dom1817

    This is great, thanks for sharing!

    :clap: :clap:

    posted in patch~ read more
  • dom1817

    Ofelia is a wrapper for openFrameworks that embed most of its functions and classes as Pd objects or Lua scripts. If you learn the logic and the syntax you could in theory program everything you can do in openFrameworks by just using Pd objects.

    The problem is that while Gem has been designed with the final Pd user in mind, Ofelia is just a set functions. This means that it's much more flexible and powerful than Gem (where sometimes you are stuck with the way it was designed), but also that Ofelia in general ends up being very confusing and distracting for a beginner.

    The solution for that would be to write better documentation and develop a set of abstractions to get stuff done quickly (like texturing on a 3D primitive, see here). This would have several advantages over Gem:

    • These abstractions could either be done with just Ofelia Pd objects or with Lua scripts. Lua scripts are actually a big thing, maybe the most important achievement of Ofelia. You are now basically able to write Pd «externals» using a high level scripting language that hides all the complexity to the user (memory management and stuff like that).

    • The graphic framework that Ofelia is built on has a very active community compared to Gem. This means that it is updated more often, uses updated software solutions and has a nice forum where a lot of questions have already been answered.

    • Once you learn how to use openFrameworks in Pd, you can move on and script your own objects, either in Pd with Lua or in openFrameworks itself.

    TLDR; I believe that Ofelia is a very young project with many usability issues, but it has a lot of potential and might actually replace Gem if enough people will start using it.

    posted in technical issues read more
  • dom1817

    I started with Pd Extended myself, it was very fun to play with but got too messy for me. Sharing patches with Vanilla users was too difficult, there were too many redundant libraries and, as you say, the release of Deken together with the 64bit compatibility issue made it obsolete.

    I think that Pd Vanilla is becoming better and better but I miss a well designed repository with all the «add-ons» available today. Many other programming frameworks share the same problem: someone develop a library in his spare time then move on to something else and abandon the project with the library eventually becoming obsolete. There is no official guideline on libraries or documentation.

    TBH I think this lack of a clear communication strategy is true for Pd in general. There are way too many isolated communities: mailing lists, irc channels, discord, international and local pd forums, generic and library-specific facebook groups, reddit threads. It would be great to see all this energy channelled into a collective effort instead of seeing people reinventing the wheel everytime (me included).

    posted in pixel# read more
  • dom1817

    Ofelia seems to require explicitly addressing the individual vertices of a mesh

    @ddw_music Actually it's quite easy to texture an image on 3D primitives with Ofelia, but I agree that doing the same by connecting [gem_head] →[pix_image]→[pix_texture] →[cube] is much more exciting and less distracting for students working on a multimedia project for the first time.

    -- Define my cube with height, width, depth
    local cube = ofBoxPrimitive()
    cube:set(100, 100, 100)
    
    -- Load an image
    local image = ofImage()
    image:load(“image.jpg”)
    
    -- Bind texture to the cube
    image:getTexture():bind()
    cube:draw()
    image:getTexture():unbind()
    

    posted in pixel# read more
  • dom1817

    I was an avid Gem user and I'm switching to Ofelia because it’s more flexible. Gem is a great tool and is very well documented, which is perfect for students, but you have to stick to its objects and the way they are designed. If you want to do things in a different way you can either write your external (IMHO not easy at all) or find a way around it, if possible.

    Ofelia requires dealing with undocumented and confusing stuff but once you get your hands dirty you can basically do everything you do in Gem with much more control and flexibility.

    posted in pixel# read more
  • dom1817

    @ddw_music said:

    Or is there another Lua syntax for arrays? Just wondering how this is handled.

    Like you say the right way to define arrays in Lua is M.array={}, Pd will complain if you use that in an object, but will let you do it in the «script view» of an [ofelia -k define] object.

    Another approach would be to use the Pd bindings, this way you define an array in Pd with a unique name (array-1) and you can read it directly in an [ofelia function] object.

    01.jpg

    posted in pixel# read more
  • dom1817

    @whale-av said:

    It looks very much like the [text] object.

    Yes, [ofelia define -k] is the way to «embed» a script in a Pd patch. You can send a [clear, read -c script.lua( message to load the script, like in a [text] object.

    posted in pixel# read more
  • dom1817

    Yes, I totally get what you mean. There are a lot of layers (Pd, Lua, OpenFrameworks) that are not very well documented and require a bit of guess work.

    Actually until the previous version of Ofelia each [of] object had its own Lua code accessible, but now they are all embedded as objects (that's why you can't see the script but only the generic help file).

    That said, when working with more complex stuff I find much easier to just write my own scripts in a code editor and load them using an [ofelia define] object. This way you have full control on what is happening and you just need to check the OpenFrameworks documentation to see the methods and properties of each object.

    Then it probably depends on how comfortable you are with traditional coding :grin:

    posted in pixel# read more
  • dom1817

    [ofRequire] loads the «M» variable from an [ofelia] object.

    Let' say you have this [ofelia function] with name $0-script:
    ofelia function $0-script;
    M.x = 10;

    You could use [ofRequire $0-script] to get the «M» variable defined in the [ofelia] object with name $0-script.

    If you do this:
    [ofRequire $0-script]

    ofelia function $0-another-script;
    print(a.x);

    This will print «10». What could be confusing is that I now use the «a» variable to access the «M» variable. That's because every float, symbol, pointer is received in the [ofelia function] with the name «a». Like:

    [100(

    ofelia function $0-another-script;
    print(a);

    This will print the number «100». Now, since [ofImage] is actually an [ofelia define] object which cointains the variable M.image, if you require this script you will be able to access the image in an [ofelia function] using a.image, like this:

    [...]

    [ofImage $0-nice-image]

    and then:

    [ofRequire $0-nice-image]

    ofelia function;
    print(a.image:getWidth())

    This will print the width of the image.
    Hope this helps!

    posted in pixel# read more
  • 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
Internal error.

Oops! Looks like something went wrong!