@starpea223 said:

I have a project due, when I opened up my patches today gem win is broken.
All other objects are still creating. Though now my gem window is opening blank instead of with image.

What Pd version?

What Gem version?

Which OS and version? (Because this type of issue is likely to have a different solution depending on OS -- the core of [gemwin] is different in Mac, Windows and Linux.)

Are there any errors in the Pd console window when you open the patch?

Without details, nobody can help. (With details, there's still no guarantee, but at least there's a chance.)

hjh

@OtherMichael said:

The problem is the fact that D05 has two instances of the D02.adsr abstraction, but the instances use the same remote message without the unique $0 identifier.
So to fix, just change "s line" to "s line-$0" and similar for receive objects.

Good catch!

Devs don't necessarily follow the forum very closely, so an "unofficial" bug report here might not get noticed.

Bug reports on github are likely to get attention faster.

Pull requests -- proposing a concrete fix in a format that can be merged in easily -- would fix it even faster --

So I just did that: https://github.com/pure-data/pure-data/pull/2247

hjh

@seb-harmonik.ar Perfect example of what I call "initialize -- run -- finalize," organized by the [t] at the top. I'd call it "textbook" except... did anybody write a textbook about algorithms in patchers?

hjh

@alexandros said:

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet,

True, but if you're doing feedback, then there's no escape from a block's worth of delay.

If not doing feedback, then the dummy inlet/outlet won't trigger errors. If feedback is involved, this inherently adds a block of delay (which can be reduced, but not eliminated, by ~block-ing a subpatch).

hjh

@alexandros said:

To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]

I think that's not necessary, because there is no patch cable from delwrite~ to delread~.

I'm quite sure I've implemented a flanger in Pd by signal --> delwrite~, then (modulated delay-time) delread4~ --> [*~ something less than 1.0] --> the same delwrite~.

hjh

@Ossicone said:

What do I need to write in the receive box in the properties of my canvas in order to
change the colour of the label
change what the label says
change the colour of the canvas itself
all at the same time

Think of it like this.

The receive name is the name of the street.

The actions (change color, change label etc) are car brands traveling on the street.

Your question is, what should I name the street so that a Chevy and a Ford and a Porsche and a Tesla and a Toyota can all drive on the street?

And the answer of course is that the name of the street doesn't matter because all the cars can travel through it.

It's a non question. You don't need a separate Toyota street and a differently named Ford street. You just define one receive symbol -- one street. And you send all the cars -- all the messages -- through the one street. "color", "label" etc are messages. The receive symbol is a send/receive name. There is no correlation between them.

hjh

@Ossicone said:

Is there a way for a canvas object to receive multiple messages at once in the "receive symbol" box?

No, but it's not necessary.

To change color, you send a message beginning with the symbol tag "color" to the canvas. It's this symbol tag that determines the meaning of the message.

The "receive symbol" is only the conduit through which the message is delivered. This can be named whatever you want.

To change color and label simultaneously, you'd send two messages to the receive symbol, with the respective symbol tags at the start of those messages.

hjh

@Aliam.Sigsaly said:

I ve heard rumors on FB group from a pretty experienced guy in Ofelia, that Ofelia is stop being developed and will be replace in Plugdata by GEM

I tried to get into Ofelia back in the day, but... if you're writing code, you need documentation, and it just wasn't there.

60Hz made some beautiful abstractions for Ofelia. I tried to revise them to support shaders but failed (my updates broke something fundamental and I just ran out of time).

Ofelia rendering looks much better than GEM but I found it to be unapproachable.

hjh

@60hz said:

What's the use of [pix_offset] here?

Currently not used. (I thought I deleted it, oops.)

It could be used for one case, though: red seems to be at the end of the hue cycle, 0 and 1. The current approach will match either slightly-yellowish or slightly-purplish reds, but not both in one range. I think (but haven't tested) you could put "0.5 0 0" into pix_offset's right inlet, shifting red away from the wraparound boundary, and then match a continuous range of reds (by pretending they're a different color).

I also found [pix_colorclassify] that could be helpful to separate channels easily

I tried it but found the results difficult to interpret. If you colorclassify and then extract the red channel, it will be sensitive to yellows as well (and there's that brown for "uncertain" which shows up also in all channels).

hjh

I think this actually works posting in case it's useful to someone.

24-0313-color-tracking-3.pd

Both the red and blue objects show up as highly saturated (bottom left). Bottom right shows the hue values, "pix_curve"-d so that only a narrow range of colors comes through strongly: there are two saturated spots, but only the left-hand one (blue) comes through.

No attempt to clean up the background in this version, but this already does a good chunk of it.

hjh

@whale-av said:

@ddw_music [pix_colormatrix] will pass just one colour or a combination set by a 4x4 matrix...

Oh right... Thanks. It's been awhile. IIRC it would also need pix_separator to avoid clobbering the original image.

hjh

Question as in the topic title.

Max/Jitter can do [jit.unpack 4] and then you get separate alpha, red, green, blue matrices (each one grayscale).

Gem can do...? Or not do...?

hjh

@whale-av said:

Plugdata has loaded the vanilla [line~] object, but has picked up the object reference for [cyclone/line~] when it searched for the help file, simply because it found it first?

If the reference feature is loading help data for a different object from the one that was loaded into a patch, I think that can pretty much be understood only as a bug. I can't think of any reason for that to be designed behavior, and it isn't useful to the end user.

The help files are not built in to the Pd binary.

Fair enough, but this thread is about a specific feature of PlugData that does not exist in pd vanilla -- hence observations about vanilla are probably not directly relevant. (Except... If vanilla always loads help from the right place, then it means the location is in there somewhere, and PlugData just isn't using it correctly here = bug.)

So is it possible that it was it [cyclone/line~] that you tested in your opening post? .... as you separated the pairs in that screenshot?

I independently tested the case without commas and found that the behavior is that of the built-in object, not cyclone's.

hjh

@gentleclockdivider said:

Regular Line~ is instantiated despite the info showng cyclone

That would be a plugdata bug then, for the Reference feature, you could go log it: https://github.com/plugdata-team/plugdata/issues

hjh

The reference panel says "Origin: cyclone." This tells you that it did not load the vanilla [line~] object -- it loaded the one from cyclone, which is modeled after Max's [line~], which does accept a series of breakpoint pairs.

hjh

@gentleclockdivider This is becoming perhaps a bit heated, unnecessarily?

I guess part of the confusion is that there are two purposes being discussed. One is display ("show all incoming midi notes that make up the chord"). The other is performing the notes as audio.

whale-av is correct that if you want to play the notes audibly, it's easier not to pack the note numbers into a single list.

• Note performance, approach 1: Notes come in --> play them polyphonically.
• Note performance, approach 2: Notes come in --> pack the note numbers into a list --> unpack the list --> play the notes polyphonically.

whale-av was trying to caution you against the second approach for audio performance. Those comments were not addressing the problem of display.

For display, I gave you a couple of examples (btw those examples were mine, not whale-av's, proper credit), so that problem is solved, I think.

max msp has a dedicated object for exactly that , says enough .

As shown, it's possible to do using core Pd objects.

If you replace the [notein] at the top with a pair of inlets (note number and velocity), and put an outlet at the end, you can save it as an abstraction and then you have a dedicated object. You could even add a list box in a graph-on-parent zone and get built-in display.

hjh

@lacuna said:

Indeed, stairs require lowered anti-aliasing filtering at the output.

There used to be CD players boasting of "8x (or 16x) oversampling" DACs.

They would do exactly what you're seeing here: 1. Zero-order hold the 44.1 kHz samples up to 352.8 kHz or 705.6 kHz. 2. Then, the final filter could be a gentle rolloff at a much lower order, rather than a very tight, high-order 20k - 22.5k filter.

But does always any DAC need filtering, even for sines below Nyquist??

If there's a zero-order hold, then yes, you do need to filter away the sharp corners. The added samples extend the frequency range above the original Nyquist -- but the zero-order hold does not accurately reflect the original signal. The sharp corners introduce high frequency energy that couldn't possibly exist at the original sample rate. It is necessary to remove those.

Reconstructing the signal from the samples could be done in a way other than upsampling and filtering. Sinc interpolation convolves the samples against a band limited impulse (band limited impulse = (sin x) / x except y = 1 when x = 0), and this can reconstruct the original signal at any time resolution, without filtering. But it's expensive, compared to upsample-and-filter.

hjh

And the overlapping-notes approach. This one updates the list for every note on/off.

24-0302-updating-note-list.pd

[pd delete] is basically:

newlist = List.new;
i = 0;
while(i < list.size) {
    if(list[i] != notenum) {
        newlist.add(list[i]);
    };
    i = i + 1;
};
return newlist;

(Or in SuperCollider, list = list.select(_ != notenum) )

hjh

Here's a pure-vanilla simple threshold (like quickthresh but simpler).

24-0302-quickthresh.pd

The threshold is currently hard-coded in the [moses] and [delay] objects. You could add a control to change it.

hjh