@blindingSlow If @porres's solution is what you meant then you can just use triggerize, select the wire you want to bend and hit ctrl/cmd-t, it will insert a [t a] for message rate wires or a [pd nop~] for audio rate which you can then move as needed with no typing. The message rate [pd nop] might be a little more efficient than a [t a] but either will be fine in the vast majority of situations and will be a non-issue unless you are using a great number of them or have pushed things to the point you need to count cycles.

@blindingSlow Do you mean the bezier/bendy wires? pd-next has them and is just vanilla pd with color themes and an option for bendy wires, although they don't loop around quite like they do in plugdata. pd-next is 1:1 with vanilla otherwise and if you use the default color theme it will be identical to vanilla.

https://github.com/sebshader/pdnext
https://forum.pdpatchrepo.info/topic/10943/a-little-pd-mod

Edit: They might bend around like plugdata on OSX, they will at the very least look nicer than on linux since OSX Tk has antialiasing enabled by default.

@blindingSlow There is a fair amount of information there but it is mostly just variations on the same methodology so once you get the basics down it comes quickly. Regarding drawing waves, sometimes it can be better to use a fixed frequency oscillator for the display and just duplicate everything for the part you are listening too. Everytime you resize an array you are reallocating the array which is not the fastest process and if you turn the frequency of your wave low down to 0.1 hz you have to wait 10 seconds for it to update the display. With a fixed frequency you avoid reallocating memory and keep the display responsive but you are asking more of from the UI with all those updates and if you are doing a good deal of manipulation to the waveform duplicating everything could be more expensive than the reallocations. Need to find the balance between trade offs for the given situation.

display.pd

Also, just remembered you had some eyesight issues, was my screenshot readable for you? If I am just uploading a screenshot of something basic which does not require the patch to demonstrate should I do the screenshot zoomed in or always upload the patch?

Edit: If you were going to make a display like this to use in a patch and not just learning you would want to stick it in a subpatch so you can use [switch~] to turn the duplicated objects off when the display in not being updated.

@blindingSlow https://github.com/pure-data/pddp

@blindingSlow
Give a read through the help files for messages and graphical arrays.

@jameslo said:

PS is it still called "duty-cycle" if it's not a square wave? I'm not a synthesist.

In the synthesis world that would generally be called variable slope. I don't think this would be variable duty cycle from the electronics standpoint either since duty cycle refers to the on vs off time and that remains constant in this use. A variable duty cycle triangle would essentially just be a [clip~ x 1].

@blindingSlow You can use [resize( method for array or [array size] and a little math to change the array's size to what it needs to be for a given frequency. To make it work with any samplerate you can use [samplerate~] to get the samplerate which pd is currently ruining at.

@ddw_music He was referring to the startup flags, start it from the terminal with -verbose and see what prints in the terminal. You could also try specifying the library on the command line, might get some extra print out that way if you are lucky. I seem to recall once upon a time getting a vital clue that way.

@dvd01osclfo You can also use the [array] objects to interact with graphical arrays.

@rph-r Didn't know escaping with [command] worked now, good to know. Wonder how many years I have been doing unneeded elaborate work arounds.

@inari All the stuff for cos_table looks to be in d_osc.c for me, not finding anything grepping m_pd. What version of pd are you using? They did change some of this with 0.55.

actually kind of breaks OOP

I think part of the reason I have issues getting OOP down is because anytime I do a search looking for elaboration on something I always seem to find one of those big long largely philosophical discussions on OOP and get sidetracked, they are often started by a comment like yours.

Edit: looks like [vcf~] no longer calls cos_maketable but [osc~] still does.

@inari Opps, I conflated t_sample and t_samplerate, pretty sure I got myself turned around on C's OOP again as well. What global? Pd is more concerned about doing things in the most efficient way possible from the computation standpoint, hence all the pointers and the like, it often leads to less than ideal code from the reading perspective. Miller has a videos explaining the guts of pd in depth plus history/theory of this stuff, it is on his website under "classes" look for something like "inside pure data." The first couple videos unfortunately have an audio issue but you can mostly make out what is important, msp.ucsd.edu. There are also some older videos which can be found on the web, I don't think those have audio issues but no idea which is better, I have yet to have the time to sit down and watch through either in their entirety.

@inari said:

However what's not clear is how these different sample rates get into the filter blocks, which use x_sr for calculating their coefficients.

But they also use c_coef and c_x which take current sample rate into account because they are type _samplerate. From d_ugen.c:

/* ------------------------ samplerate~~ -------------------------- */

static t_class *samplerate_tilde_class;

typedef struct _samplerate
{
    t_object x_obj;
    t_float x_sr;
    t_canvas *x_canvas;
} t_samplerate;

static void samplerate_tilde_bang(t_samplerate *x)
{
    outlet_float(x->x_obj.ob_outlet, canvas_getsr(x->x_canvas));
}

static void *samplerate_tilde_new(void)
{
    t_samplerate *x = (t_samplerate *)pd_new(samplerate_tilde_class);
    outlet_new(&x->x_obj, &s_float);
    x->x_canvas = canvas_getcurrent();
    return (x);
}

static void samplerate_tilde_setup(void)
{
    samplerate_tilde_class = class_new(gensym("samplerate~"),
        (t_newmethod)samplerate_tilde_new, 0, sizeof(t_samplerate), 0, 0);
    class_addbang(samplerate_tilde_class, samplerate_tilde_bang);
}

/* -------------------- setup routine -------------------------- */

void d_ugen_setup(void)
{
    block_tilde_setup();
    samplerate_tilde_setup();
}

I think if you do the math it will work out but I could be missing something, OOP in C plus heavy pointer use plus math symbols thrown about with pointer symbols always leaves me a but unsure of what is going on if not completely lost.

Actual sample rate comes from c_x and c_coef in struct hipctl and are of type t_sample which is buried at the bottom of d_ugen.c. Or that is what I am seeing, I am just starting to learn about digital filters and pd's pointer abuse often makes me go cross-eyed, but it is getting easier.

Edit: Should mention, I am mostly posting to see if I got it right. I don't really know but hope to be corrected and elaborated on.

Edit 2: I think i got it right and 44100 for x->xsr could be any number if the equations were tweaked to suit. But does the choice of 44100 have some logic behind it?

@rph-r If you have the gui running you can write a gui plugin to write the text file, you would have something like this in your patch:

[list prepend plugin-dispatch append_log]
|
[list trim]
|
[s pd]

and then in your gui plugin which needs to be saved in your path with the -plugin.tcl suffix:

set f [open log.txt a]

proc append_log {args} {
    puts ::$f $args
}

Untested, been awhile since I wrote to a file in tcl and like I said this method requires the gui to be running since there will be no tcl without it.

@ddw_music said:

I know, I know... planning to upgrade to Ubuntu Studio 24.04 over the winter holiday... then hello pipewire.

Might want to check the pd github, there is at least one pd killing bug when using Pipewire's Jack, saw it yesterday but did not look into it since I have also let updating my system slide and don't feel like updating quite yet.

Edit: never mind, you use plug data. But might be of interest to OP in case he decides to update so I will leave it.

@rph-r The only way Pulse could be the culprit is if you are running jack/portaudio through Pulse, but that is generally not done since Pulse has too much latency for realtime audio. I can't speak of portaudio (never used it) but with jack the general setup is to either have Pulse as a client of jack or have jack kill Pulse when it starts and restart Pulse when it shuts down. I would guess that the later is your setup, Pulse configures your audio card and jack is not great at doing that so just accepts what Pulse set it at. You might be able to get jack to set it properly or configure Pulse to use 44.1. Some soundcards jack just can not configure as far as I can tell so if you are using Pulse and having jack kill Pulse you need to either configure the soundcard manually or do it in Pulse before starting jack, I have to do this with my laptop, jack can not select between headphone and speaker outs and will use which ever is enabled when it starts.

Edit: I suppose it could also be the case that your soundcard is 48k only?

@whale-av said:

Using Pd under Linux I think you can set audio thread priority with the -realtime startup flag.

Doesn't the realtime startup flag just enable the use of realtime audio (the default)? --help does not mention arguments, is this one of those features which was only documented on the dev mailing list? But in linux we do have various ways to give things greater priority such as nice and can go all the way to running an application on its own isolated core and even use a preemptable kernel so an application can have a higher priority than the kernel.

Got a chance to finish this up, think I got everything as it should be but could use more real world testing most likely. There is an error in the knee calc range but I decided to keep it for now, it softens up the knee a bit more and I find it easier to keep things where you can not hear the knee. If you use your eyes more than your ears you will probably want to put a little more knee in than you are used too. Added a sidechain which is good fun in pd as well as signal and message rate gain reduction outs so you can monitor gain reduction and get essentially free multichannel expansion for those times you don't need or want separate level detection on each channel.
kcomp~.pd
kcomp~-help.pd