One of the first things that happens when you plug [notein] into a monophonic synth design in Pd is that overlapping notes break the envelope: if, say, C and D overlap with D sounding and you release C, then the D note gets cut off!

If you want it to behave like a standard VST synth with voices = 1 and "legato" on -- the logic ends up being relatively involved. So, for my students' sake, I wrapped it up as a couple of abstractions.

noteglide-help.pd noteglide.pd midimonoglide-help.pd midimonoglide.pd

Note that it depends on cyclone -- a note-off message needs to delete a note number from a list, which is a missing feature from [list] (but implemented in cyclone as [zl filter] -- sure, it would be possible to implement with a list iterator, but I'm willing to bet [zl filter] is faster).

A second object supplies the glide.

hjh

As far as I can see, it's handling the [OSCroute /mouse] correctly -- otherwise the print wouldn't fire.

But it is sending the number as a string, which is a baffling choice by the grasshopper designers (maybe a bug on their side).

You might try [OSCroute /mouse] --> [fudiformat] --> [fudiparse] ...? Though my memory is fuzzy on that. I think that can convert number-as-string to a proper number. (Though I don't understand the single quotes in the printed error output either... so this might not do it.)

hjh

@whale-av ah ok, so the problems are mainly in the handling of type tags. That's fair.

I knew about the numbers-in-command-path problem (surely that's fixable?). I hadn't thought about sending messages from Pd. SuperCollider at least just renders the value into an array so it doesn't complain whether the number is a float or int -- but now that you mention it, I could imagine other software that may require one or the other (and Pd being int-less would have an extra challenge there).

Thanks for the explanation.

hjh

Is there a benefit of using mrpeach over the vanilla net send/receive objects? I don't quite see it, and I couldn't install mrpeach for some years, so I was surprised at the direction this thread took.

I vaguely recall that, some years ago, vanilla support for OSC was subpar and mrpeach filled the gap, but as I understand it now, vanilla support has improved and there isn't much concrete reason to add a dependency. But maybe I'm missing something.

hjh

@whale-av

I believe that if your LFO is within the blocked sub-patch...... and the sub-patch has no inlets or outlets..... you can set any block size you wish.

Unfortunately, restructuring the patch as follows doesn't resolve the issue. (The sub-patch has control inlets, but they aren't time-sensitive. There aren't any inlet~ or outlet~ objects.)

So there is something else going on. My best guess would be that Ofelia's draw timing is quantized to the main patch's block size, and doesn't care about subpatch reblocking. (The "bang" feeding tabwrite~ is coming from the Ofelia backend, not from [metro] or any other Pd timer.)

hjh

Something that might be obvious to some people here, but wasn't obvious to me --

If you're trying to sample an LFO signal and use this to control video, make sure that the sample rate is an exact multiple of the control block size. This is not the case for 44.1 kHz vs a 64-sample control block (but it is the case for 48 kHz vs 64 samples).

In this patch, it looked like the logic was correct, but the LFO "jumps" about once per second.

ofelia-timing-glitch.mp4

But if I start JACK with a 48 kHz sample rate, then the same patch is perfectly smooth.

Curiously, though, setting the block size to the largest power-of-two factor of 44.1 kHz ([block~ 4 1 1]) doesn't affect the behavior at all. (Fun fact: 44100 = 2*2 * 3*3 * 5*5 * 7*7.)

Probably this affects any similar use of [tabwrite~] but the impact is more dramatic when it's controlling graphics.

Something to be aware of...
hjh

@60hz

Ah OK, it turns out that the main problem was that I hadn't positioned the light far enough above the scene.

Ohhhh... and now I see why it worked right away in your help patch -- because you positioned the geos below z = 0 (with light source at z = 0). I was looking for an initializer for the light position, but that wasn't it at all.

Gracious, I'm bad at this

hjh

@60hz -- May I ask, do you have some advice for using [of.arealight], for example?

I just tried to draw a sphere with an [of.arealight] in the patch, and the only effect of the lighting is to make the sphere darker. I don't see any sort of shading for the shape's contour.

But, your of.arealight help patch does show at least some translucency(?) effects...

A bit pressed for time today, not much leeway to experiment with it, so I thought I'd ask what is the "right" way to set it up?

hjh

If you're toggling between any two values a and b, then you can calculate c = a + b -- then to toggle a value x, it's c - x (one math operator per flip) -- the catch here is that math operations where a constant is on the left but the right side may vary are awkward in patchers. Max introduced e.g. !- (I think) for this but Pd still requires you to work around the limitation ([swap], or [expr]).

You could do

[f]
|
[- constant] (substitute a+b here)
|
[* -1] (or maybe there's a unary negation operator, I forget)

When toggling between 0 and 1, the constant is (intuitively) 1 -- but the approach can generalize to any two numbers.

hjh

Interesting progress on this thread! I'd dropped off -- will have to catch up.

Of scripting languages -- I'll get myself in hot water for saying this, but every really cool max or pd project I've seen involves some scripting objects somewhere. There are some things that are really hard to say with patch cords, that are very easy to say in imperative (or functional!) code -- and other things that are easy to say in patch cords that are harder in code (such as, my GUIs in SuperCollider usually have some model-view-controller glue underneath -- which is robust but you can't explain it in two sentences like you can explain a pd slider wired up to something).

Ofelia is quite nice for providing access to coding style logic with patches inlets and outlets.

hjh