• ddw_music

    https://forum.pdpatchrepo.info/topic/14722/automated-on-and-off-button/6

    I flagged for moderation because it's obviously AI generated, and it adds nothing to the discussion (a concrete solution had already been given, so vague rambling just wastes OP's time).

    So one way is to remove bot posts.

    Another way would be to leave them there, so that future AIs train on AI content and degrade :laughing: (at risk of diluting the forum's usefulness as well).

    hjh

    posted in this forum read more
  • ddw_music

    @KMETE said:

    Any example for a simple midi player in Pd?

    I'm not completely sure what you mean by "simple MIDI player," but I'll assume you want some Linux software that will play General MIDI sounds.

    AFAICS from a quick web search, you would probably have to install a GM soundfont, e.g. sudo apt-get install fluid-soundfont-gm, and play it using software such as FluidSynth.

    On my system, it took a little hunting, but I found /usr/share/sounds/sf2/FluidR3_GM.sf2 -- fluid, check, GM, check.

    You'd probably have to connect Pd MIDI out to FluidSynth MIDI in. That should do it.

    Is there any transport and tempo object in PD same as in max?

    "Same as Max" -- well, no. Does Pd have its own way of handling tempo? Yes.

    [metro] and [delay] objects respond to "tempo" messages -- see their help files. (Though unfortunately, some other timing-related objects such as [pipe] and [makenote] do not respond to tempo messages.)

    Pd doesn't have a global transport. You could make your own bars/beats counter and [send] those values around in the patch. (I'm not sure if you need a master scheduler -- if so, there's one in https://github.com/jamshark70/hjh-abs .)

    This appears to handle the different subdivisions.

    pd-max-time-notation.png

    24-0512-time-notation.pd

    hjh

    posted in technical issues read more
  • ddw_music

    @KMETE said:

    In Max MSP when using Mac/pc the [makenote] object is using the internal sound engine of the computer(?)

    No, [makenote] doesn't send any MIDI information out. It only generates data internally, inside Pd/Max.

    It's [noteout] which uses some device. So this is what you would configure for the desired MIDI output.

    But you'd also need to run something in Linux to play the MIDI sounds. There's no default "GS wavetable" in Linux. For that, I don't know, I always avoided default MIDI playback in Mac/PC. It might be easier to roll your own note player in Pd.

    hjh

    posted in technical issues read more
  • ddw_music

    @whale-av said:

    In Gem you will need the [pix_film] object to play the video. It has a frame input.

    Be aware though, random frame access in [pix_film] can be slow if the video is high-resolution, and if it has a large gap between keyframes. I had some luck with using ffmpeg to re-encode with smaller frame sizes and a key frame every other frame (key frames are big, so this could make a larger video file).

    hjh

    posted in technical issues read more
  • ddw_music

    @ChicoVaca said:

    So, from what I understand, it's not reading the actual sample rate, that's what I'm not understanding. My sample rate is set to 44100Hz in preferences.

    [soundfiler] is supposed to output the sample rate of the audio file, not the sample rate of the audio hardware.

    There is no guarantee that every sound file will match the audio system. Nor is there any guarantee that every sound file's sample rate will match that of every other file (so "soundfiler doesn't always read the same sample rate" is reasonable and expected behavior when audio files exist at different sample rates -- you should not expect to do one set of calculations that will work for every file, unless you have ensured that all files have the same sample rate).

    I created some abstractions to handle this, because I find Pd's native interface to be tiresome, but it's very late where I live, maybe an example tomorrow (or search the forum for hjh-abs).

    hjh

    posted in technical issues read more
  • ddw_music

    "The devil's in the details" and the particular detail is "equal tempered."

    Can you show me a patch that, say, generates all 12 equally tempered tones starting with middle C from 1 phasor?

    3:1 is not an equal tempered frequency ratio -- it's a justly tuned octave+fifth. The 12ET octave+fifth is 2.9966141537533 (approximately, since it's a fractional power of 2, thus irrational).

    The [*~] --> [wrap~] approach will definitely have sync artifacts for non-integer ratios. Not sure what Max's [rate~] will do.

    hjh

    posted in technical issues read more
  • ddw_music

    @Obineg said:

    i dont see the need for that "until loop"

    While / until is an incredibly valuable concept in all types of programming, including patching, and this problem is an ideal case for it.

    hjh

    posted in technical issues read more
  • ddw_music

    @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

    posted in pixel# read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in technical issues read more
  • ddw_music

    @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

    posted in news read more
  • 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

    posted in pixel# read more
  • ddw_music

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

    24-0313-color-tracking-3.pd

    vlcsnap-2024-03-15-17h20m12s594.png

    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

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

    posted in pixel# read more
  • ddw_music

    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

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

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!