@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?