• ddw_music

    @oid said:

    Frustration got me to throw together a few abstractions today to make easier to deal with [trigger], [pack], and [unpack], it allows you to add or delete inlets anywhere, not just at the end.

    This ranks very very high on my list of annoyances with Pd: that inserting or deleting from program logic in [t] destroys connections, making it error prone to replace them.

    I'd even suggest logging this as a feature request to include in vanilla [t] and bypass the abstraction.

    hjh

    posted in technical issues read more
  • ddw_music

    RTFM department: send a "loadbang" message to the subpatch.

    Should have looked through the help patches more carefully first.

    Never mind!
    hjh

    posted in technical issues read more
  • ddw_music

    I was just investigating the possibility of dynamically creating a number of instances of my [stereofile] abstraction (for instance, to load a list of soundfile paths into separate instances).

    If an abstraction contains [loadbang], and you create it by hand, [loadbang] fires and initialization proceeds as you would expect.

    But it seems that sending a message "obj x y abstraction-name arg0 arg1" to a canvas does not call [loadbang].

    pd-dynamic-no-loadbang.png

    Perhaps I'm doing something wrong, or this is one of those "we depend on dynamic patching to fill in some gaps, but you really shouldn't depend on dynamic patching" situations :laughing:

    Known workarounds?

    hjh

    posted in technical issues read more
  • ddw_music

    @atux said:

    I state that in Purr-Data my patch above works perfectly, it performs a clean discete glissando of microintervals, from midi note 60 upwards.

    Out of curiosity I tried to open the same patch in Pd version 0.51.4: nothing works! The counter object stops at 10 (why?),

    I can't reproduce this problem in my system -- opened your exact patch file and [counter] is fine.

    IIUC [counter] is from cyclone. Purr Data bundles cyclone within its own installation. Standard Pd requires it to be installed as an external. Possibly there's a problem with this installation of cyclone.

    the bendout part has no effect, as if it were not there.

    I can't reproduce this either. On my system, [bendout] is sending and other apps receive it, no problem.

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo said:

    @whale-av @ddw_music I've written assembler for at least 3 different processors and I remember all of them being easier to learn than Pd due to their regularity, completeness, consistency, and sometimes orthogonality

    Well... yeah... there are reasons why graphical programming environments haven't taken over computer science... because they're simply not very good at the things CS needs. (One could make the argument that a great many computer musicians can get by without those things, sure.) In particular, data structures and "scope of influence" (such as local variable scope, or public/private variables and methods) are both highly articulate in modern text languages, and sorely underdeveloped in both Pd and Max. ([text] helps but I suspect everything is O(n*m) where n = rows, m = columns.)

    There are reasons why my live coding dialect (demo linked below) is implemented in SuperCollider and not Pd/Max. In theory it may be possible to create an abstract syntax tree in [text] storage, but to be frank, it isn't worth the effort. If I really wanted that in Pd, it would be better to write the parser/compiler in Lua or Javascript and embed (but SC, by pulling the control layer out of the audio loop, is also designed for glitch-free dynamic instantiation of synthesis units, which Pd is decidedly not).

    I wonder if @ddw_music is trying to teach that to students who don't view it as their primary objective, using a language that's particularly bad at conveying it?

    I fully understand and accept that most of the students at this conservatory won't grasp the full implications -- that's fine. Still, every year, there are a few students who do soak it up and they can't get enough. For them, I think it is helpful to present a framework under which, for example, counting and list iteration could be understood as variations on the same structure, rather than discrete cases.

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo All of this is great, thanks.

    I had figured out simple iterative (and nested-iterative) cases on my own -- but, I know what I'm doing in SuperCollider (it's now about 7 months shy of my 20th anniversary with that software) and it took me over a year to figure out in Pd. Something is not quite right with that.

    One factor is pedagogy. I'm now in my third cycle of teaching "interactive multimedia" using Pd. The first two times, the second or third lecture was about dataflow rules. snoring from the desks This semester, I replaced that lecture with "how to count" -- "1. This is a simple, concrete use case that anyone can understand. 2. You will have to do this hundreds of times, so it's good to learn a reusable pattern" -- and it introduces [f] storage, hot and cold inlets, and I use a trigger after [f] for the "next value" and "action" branches (introducing right-to-left, as well as the solution to the order-of-connections problem) -- most of the dataflow rules! But more useful.

    It also introduces initialization -- you can't count without setting the first value -- and from there it's a small step to a general pattern that I use a lot (initialize -- process -- finalize, with a [t] at the top banging each of these stages sequentially). So then every time this comes up (iteration over an array or list etc.), I can say "remember, we already talked about this -- initialize-process-finalize."

    By contrast, https://forum.pdpatchrepo.info/topic/13936/playing-notes-sequentially -- "There is an inlet, that is a list in the format X1 D1 ... Xn Dn, where X is a MIDI value (note), D is a time value (ns) and n >= 1. For example 90 100, works fine, but I have no idea how I can do this sequentially (like 90 100 96 200 90 200)." Of course new users have no idea -- because nobody teaches principles of iteration. You have to guess based on examples (whale-av's answer in that thread does show a useful general pattern, but it isn't discussed as such).

    About recursion, I had faintly begun to suspect that it would be necessary to implement one's own stack. But, I have to admit here that I would be unlikely to try because I (speaking just for myself) can get there faster in text. It's nice to see it laid out, though -- thanks for the example! (Though, with tongue in cheek, I note that "if you've ever programmed in assembler, you'd know exactly what to do" is not quite a strong endorsement of accessibility :wink: )

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo said:

    @whale-av I'm dying to show you how straightforward it is to port procedural algorithms to Pd but I want to enjoy your admiration a little longer :)

    I'm dying to see this, as I'm continually impressed with how obscurantist graphical languages are about procedural work. (I've actually gotten reasonably good at some cases that are not exactly simple. Recursion eludes me though, because it depends in procedural languages on local stack frames, which seem... inconvenient in Pd.)

    hjh

    posted in technical issues read more
  • ddw_music

    @vobb said:

    Hello and thanks for taking the time. FFT is not restricted to power-of-two but it runs most efficiently that way, unless this SE thread is completely off it's O(N log N) vs O(N^2))

    Good link, thanks, I knew that the optimal FFT recursively divides the frame in half, but hadn't thought about other small-integer factors. Actually I can't quite visualize how it works except for the optimal case, but I'll trust that the FFT library knows what it's doing.

    It's very likely, though, that the pitch will be a non-integer number of samples. And syncing the block size to a changing pitch is likely to be... amusing.

    Anyway hope you get some useful data from it.

    hjh

    posted in technical issues read more
  • ddw_music

    First, FFT is restricted to power-of-two frame sizes, so you can't match the window to an arbitrary pitch.

    Second, if I understand correctly, fft's frame size is controlled by a [block~] object in the same subpatch performing the fft.

    hjh

    posted in technical issues read more
  • ddw_music

    @kyro Was pondering that... does it need to be a one-sample delay? To go to a reasonable extreme, 24 ppq at 200 bpm, at 44.1 kHz = 44100 / 200 * 60 / 24 = 551.25 samples per tick. A full control block's delay should be fine, probably more reliable.

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!