Incidentally I've made a lot of progress in the last couple of days -- I've got a working prototype of the simple "gain" shader where the parameter is "soft"-defined in a descriptor file rather than hardcoded in the Lua script. It will support single values, pairs, triplets, and RGBA colors in 4 variants (float and integer, times with alpha vs alpha assumed to be 1).

Need to clean it up but I think it will be pretty cool.

hjh

Very cool to see some of Ofelia's extensibility -- and nice to see more shader examples (even if 3d seems not fully supported yet).

hjh

@JackOats said:

Actually, when I click on File/New I get a blank page.

I'm not familiar with Automatonism, but what you've described here is the default Pd behavior for a new patch.

If there is some other behavior for a new patch that you're used to, it's because of an add-on or mod, which may have an installation or configuration problem, or maybe it's incompatible with the newer Pd version. (But I've never done any mods, so someone else would have to help you here.)

hjh

@jocke said:

@ddw_music That is a cleaner way of doing it. But I think it will give me the same problems I had before the [spigot] since the BSP seem to send the message twice which would mean that both the note_on and the note_off messages would reach the [vline~] at the same time.

It won't. [moses] means: if the incoming value is less than the set value, send the float out the left outlet. If it's >= the set value, send it out the right outlet.

There is no way that a single real number can be both < x and >= x -- so the float can go out only one of the outlets. It's impossible to have one incoming message go out to both outlets at once.

hjh

In my class demos about envelopes, I did it like this:

(velocity source)
|
[moses 1]
|       |
|       (envelope attack/decay segment messages)
|
(release segment message)

And both of the messages to vline~.

Instead of sending the velocity down both branches and stopping the flow for one of them, this way splits the velocity into on and off paths directly.

hjh

@Jona said:

@ddw_music i just wanted to say that it is possible to scale an fbo (and strange, that the doc says the opposite)...

Yeah, strange, but this is what I read:

draw(...)
void ofFbo::draw(float x, float y, float width, float height)

This allows you draw everything that's in your fbo to the screen using any height and width. Any stretching is up to you to handle appropriately.

https://openframeworks.cc/documentation/gl/ofFbo/#show_draw

... where the equivalent method of ofImage says "... with any attendant scaling that may occur from fitting the ofImage into the width and height."

It's moot for these pd abstractions because I'm allocating the fbo to match the image size but it struck me odd.

I'm glad to have some bandwidth between semesters to contribute something to help future users 😁

hjh

@Jona "the learning curve is steep (depending on your background), because you need to learn several languages at once (lua, c++, open frameworks, opengl, shader, emscripten, java script etc.)..."

For example, if you draw an ofImage and specify a width and height, it will scale the image to the width and height. If you do the same with an fbo, then (according to the documentation) it will not scale. Or, if you draw an image, it's the right way up, but if you texture it onto a geo, it may be rotated 180 degrees. Fine print like this is maddening. It suggests that the development focus is on the implementation internals rather than the user's experience of the object interfaces. There may be good reasons for that but I'd love to see another layer on top of this to make behaviors more consistent.

Granted, I'm coming from an environment where OOPy polymorphism means that different classes should strive to implement the same method name in ways that are basically compatible. Maybe this isn't possible or desirable for graphics in the same way (I can understand shaders' more intimate connection with the hardware), in which case the static is between my expectations and the reality.

Anyway, maybe I'm wrapping my head around it by now...

hjh

Made some progress... this is transferring the image data into a FBO, and applying the shader at that time, and then using the FBO as a texture onto a plane. In principle, it should be possible to rotate/translate the plane without affecting the shader's behavior.

Integrating this into the [of.] abstractions' plumbing may have other challenges, but it looks like it may very well work.

FWIW: This is hard to figure out. Really hard. Open Frameworks doesn't do much to smooth over any rough edges in interfaces. (Even here, if I switch off the fbo, the image flips upside down.) The abstractions being discussed here are really necessary. From time to time, I hear people complain about the intense learning curve for SuperCollider, but in my experience, Open Frameworks is a million times worse. Little gotchas hiding all over the place. Every little step in this process has been literally days to work through. Ofelia is powerful, yes, but usability is not there yet.

hjh

@Claire080499 said:

@ddw_music Okay, i thought as much, I'm only final stages of my project and I've hit this block. Is there anyway of converting the the midi from the patch below into audio, or get it into an array? I know there must be but I'm struggling to find the solution.Midi chords to audio.pd.

That requires a synthesizer that responds to MIDI input. (This is the same as in any DAW, where a MIDI track routes the MIDI messages to a VST or AU plugin and passes the plugin's audio output to an audio channel. It's a very common architecture.)

In Pd, you can use Christof Ressi's excellent vstplugin~ external to load VST2 plugins into Pd directly. (Assuming you have some installed already -- if not, you could look for Vital. It's a very cool new free softsynth, modeled after Serum. I tried it once with vstplugin~ and it worked a treat.)

Or you can build a synth instrument using Pd's signal processing objects.

hjh

@zberkowitz said:

I thought so too, but other implementations of what I believe are the same kind of biquad formula don't seem to have this issue. 31 Hz with an octave bandwidth doesn't seem extreme!

I'm doing some testing in Supercollider on the same thing (also a biquad implementation of a peaking EQ style filter) and so far not experiencing the same issue.

One possible difference is that SC filters store coefficients as double -- meaning (I think) that the coefficient multiplication/addition is also double. Signal ins/outs are single-precision in both SC and Pd, but if the internal math is double in SC and single in Pd (a quick glance at the Pd source suggests that this is the case), that would likely translate into lower noise in the SC filters.

Maybe?

hjh