-
ddw_music
@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
-
ddw_music
I think this actually works posting in case it's useful to someone.
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
-
ddw_music
@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
-
ddw_music
@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
-
ddw_music
@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
-
ddw_music
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
-
ddw_music
@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
-
ddw_music
@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
-
ddw_music
And the overlapping-notes approach. This one updates the list for every note on/off.
[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