• seb-harmonik.ar

    @high_output-5000 no. a couple times in the past I've used awk for stuff like this (use awk on the .pd file)

    you could try wrapping the row in an abstraction, then give the abstraction an argument to set the row number. Then you would just have to set each column number..

    another solution might be to create a one-time dynamic patching section, and just use it to generate the matrix. you can set the send and receive names before you create the objects, then create them with the 'obj' canvas message to the canvas

    I've used [matrix~] from iemmatrix with [numberbox_matrix] from iemgui to do this kind of stuff. Because then you can also set an 'amount' for each signal

    edit: for example this polysynth: https://github.com/sebshader/instr/tree/master/datalogue
    (tho the editor is separate from the synth/signal matrix & the synth guts are pretty ugly)

    posted in technical issues read more
  • seb-harmonik.ar

    @ddw_music I guess I would say that might be a use of an argument to specify a name, but I can see now why you might want it dynamically settable via symbol box or something.

    I meant: if you restructure the dsp graph, I think the audio graph will stop and start whether you do it manually or not, while it gets recomputed. And I think that applies to changing send/receive/throw/catch names.

    Slightly OT: the reality of the situation is that Pd is not as ideal as supercollider for live-coding, since so much stuff happens on the audio thread (namely memory allocation for classes/objects and audio graph recomputation)

    I think you could still get around dynamic patching if you used a bunch of global state to lookup static abstraction names/templates but that may not be ideal, and may still need iemguts for [closebang] to unregister.
    because ironically [receive] can't be set..

    posted in technical issues read more
  • seb-harmonik.ar

    @ddw_music I'm unsure why they are different pairs of classes, but I don't see what couldn't be done with the [catch~] -> [send~] method that would need dynamic patching..

    if you want a specific [send~] to send to specific [receive~]s, just set it from the [receive~] side.

    similarly, if you want a specific [catch~] to get stuff from specific [throw~]s, set it from the [throw~]s

    Maybe it's due to implementation reasons?

    edit: also see this recent relevant thread on the pd-dev list: https://lists.puredata.info/pipermail/pd-dev/2023-01/023195.html
    it seems like the reason is to avoid a block delay?
    anyways the ext13 library has settable [send13~] and [catch13~] objects too, that might be easier than iemguts and dynamic patching.. though you have to turn dsp off and on again (but if you're dynamic patching signal objects that's the case anyways I think)

    posted in technical issues read more
  • seb-harmonik.ar

    seems like it.
    looking at sched_tick and the 2 different schedulers in m_sched.c it seems like the order is:

    1. Gui is polled (where pd gets the 'click' message from tcl/tk, triggering the [bng] to output)
    2. clock callbacks occur (this is where the [bang~]'s bang gets output) for the 'next' 64 samples
    3. 'current' scheduler time is incremented 64 samples
    4. audio is processed for the block (this is where [bang~] sets the clock callback for 0 logical time)

    really, since [bang~] happens every cycle we should think about step 4 happening 1st because there will be a callback already on the set clock list from the dsp cycle before pd gets the click from the gui. so

    4(4). [bang~] sets a clock callback for 0 logical time.
    5(1). pd gets the 'click' event (still at that time) so [timer] is set and [spigot] is opened
    6(2). the clock callbacks are triggered, and the clock callback for [bang~] triggers for logical time 0 (relative to the 'click'), outputting and triggering the [timer]
    7(3). logical system time is incremented for the next dsp tick

    posted in technical issues read more
  • seb-harmonik.ar

    v. 0.53-1 has actually been ready for a bit, with a new graph_open color type (for opened GOP subpatches in the parent, currently a grey box)
    unfortunately my macbook died and my new laptop isn't powerful enough to run VMs well I think (not macos anyway) and I had a lot of trouble cross-compiling wish.
    So, windows and mac builds may take awhile.. unless someone else wants to build.. maybe I'll try to get some CI thing to make a release..
    https://github.com/sebshader/pdnext/releases/tag/0.53-1

    posted in news read more
  • seb-harmonik.ar

    @jameslo well the time factor will be different by a constant because it's happening every sample vs every ms but it seems like the same exact equation to me (feedback and all)

    except for different inlet order

    posted in abstract~ read more
  • seb-harmonik.ar

    @adtubu you can just use [rpole~] as an audio-rate integrator

    posted in abstract~ read more
  • seb-harmonik.ar

    if you want to generate the same envelope for the filter you can use

    [rpole~ 1]       period in samples*4
    |                 /
    [/~ 1]
    |
    [sqrt~]
    

    (period in samples*4 goes to right inlet of [/~ ])
    when you start a new note, clear the [rpole~] and send it another [1 (

    posted in technical issues read more
  • seb-harmonik.ar

    @Pathagas in order to use an up-to-date version of tcl/tk you have to 'cd' into the 'mac' directory of the source tree and follow the instructions/"help"s in the scripts to create the .app bundle with a certain version of wish. the version of wish bundled with macos might be too old.
    Also some people have had some luck changing the samplerate in pd to match the samplerate in the "Sound" System Preferences, and/or deleting the pd preferences file.

    It could also be that portaudio is just out of date, and you can build a newer version of portaudio to include with pd by using the update script in its folder. But idk if it's even a portaudio bug... (and if it is, if they're aware..)

    posted in technical issues read more
  • seb-harmonik.ar

    @atux you have to compile the boids2d external. I was able to do sudo make in terminal in that folder and it worked.
    (you need dev tools installed, like a compiler and make)
    If you have glibc version >= 2.31 you could try to use the ones I compiled too: boids-1.1.1.tar.gz

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!