• jancsika

    @60hz Thanks. It should be a pretty easy change to one of those options.

    posted in technical issues read more
  • jancsika

    @60hz Yeah, that shouldn't be a problem.

    The difficulty with [cnv] is it that it has a "selection size" that is independent of the size of the drawn rectangle. Worse, it is the "selection size" and not the drawn rectangle which Pd counts as the bounding box for the rectangle. This means that in Pd Vanilla the drawn rectangle can extend arbitrarily past the bounds of a GOP rectangle, which is just plain bonkers.

    posted in technical issues read more
  • jancsika

    I'm talking about the blue square-- the "anchor" you can use to resize it.

    Would it improve things if this blue square was always in the corner of the drawn rectangle of [cnv]?

    It's easy to make it partly transparent, but it may be better to display it inside the main rectangle so it doesn't get in the way.

    posted in technical issues read more
  • jancsika

    For me, the most important point of this thread is to learn dataflow vocabulary for the text-programming concept of function calls.

    This is a decent starting point, but more and more it will lead you astray.

    For example, your initial text pseudo-code leads quite naturally to a notion of passing around references to objects, which is what Pd scalars typically depend on. That's like anathema in a diagram-based language, and it's the reason nearly nobody uses data structures in Pd aside from demonstrating cleverness. But there's nothing in the text-based programming world to clue you in to that.

    Additionally, there are useful patterns in Pd that you won't discover by thinking in terms of functions. There's a common pattern of sending a message through an object chain to be filtered, a lot like a vertical version of piping data in a shell script. There's another common pattern where the same message flows through an object chain unchanged so that each abstraction can trigger its own side-effect. Finally, you could leverage ingox's "function" abstraction to create an object chain that steps through a state machine in a quite readable way. (In fact ingox's wrapper may be more abstraction than you need for your state machine since you could just make a custom abstraction with the exact kinds of inputs/outputs that you need for that specific case.)

    posted in technical issues read more
  • jancsika

    @Boran-Robert That's a tricky object:

    1. It's bounding box defaults to being smaller than the drawn rectangle, so it doesn't work like every other gui object in Pd.

    2. The small blue square is a workaround for that. (I assume you are in editmode, as it disappears in run mode.)

    One possibility-- I could resize the square and move it to be inside the drawn rectangle. Would that solve your problem?

    The other possibility is to simply make the entire drawn rectangle draggable. But Pd users are like magnets to obscure features-- I have no doubt someone has found a use for this strange behavior...

    posted in technical issues read more
  • jancsika

    For me, the most important point of this thread is to learn dataflow vocabulary for the text-programming concept of function calls.

    I don't think Pd is a dataflow language. The signal diagrams might count as that. But the non-DSP objects are a weird kind of Rube Goldberg-machine of imperative programming. (And they can interact with the DSP objects in a diagram.)

    It creates an irony where the most difficult conceptual part of Pd-- DSP programming-- gets the simplest diagrams. E.g., all objects are guaranteed to receive their inputs before they compute their outputs. While the simplest conceptual part-- sending sporadic arbitrary data to immediately compute an output-- requires special objects to keep the order of operations correct.

    posted in technical issues read more
  • jancsika

    @ddw_music

    I'm afraid I'm not quite following you.

    Let me try again.

    Imagine you've got a single sequencer in the top level of a patch.

    Feeding into its input, you have a global receiver [receive in]. (For the purposes of this example it's global. This is just didactic, and we could fix that later if we wanted.)

    At the bottom of your single sequencer, you are connected to a [send] object with no argument.

    Now, you are also going to build an abstraction which you can use with that same patch. It is not part of the sequencer, it's something different. Inside this abstraction you have something like this:

    [inlet]
    |
    [list prepend $0]
    |
    [send in]
    
    [receive $0-my-output]
    |
    [outlet]
    

    Finally, you just have your sequencer slice off the head of the incoming message to [receive in], prepend it to the string "-my-output", and send it to the right inlet of the [send] with no arguments. Finally, you trim the list selector off the rest of the message and have your sequencer handle that message as it normally would.

    This will result in the sequencer sending a message only a single abstraction instance.

    Thus, you have a single state machine accessible by an arbitrary number of abstractions which can advance the state by sending and receiving their own arbitrary messages to and from that single sequencer.

    but it also means there's no harm in extending the system's reach.

    There is harm in extending it the wrong way. For example, the "init" message of the iemguis is often a harmful feature. Imagine tracking down an insidious bug in a program like this:

    |
    [float]
    |
    [tgl]
    |
    [== 0]
    |
    

    vs. this:

    |
    [float]    [preset_node]
    |         /
    |        /
    |       /
    |      /
    |     /
    |    /
    [tgl]
    |
    [== 0]
    |
    

    If you get unexpected behavior from the first example and forget (or never knew) that there's an "init" checkbox for that [tgl], you have to do creative debugging in order to find it:

    1. Right-click and open the dialog to check init state, probably because you hit such an insidious bug before.
    2. Close Pd, run with the "-noloadbang" flag because you've learned that if that fixes the bug there is almost certainly an iemgui init or a [loadbang] deep in a subpatch somewhere.

    But the one thing you can't do is simply read the patch! Not only can you simply read the 2nd example, the secondary loadtime data flow is immediately obvious.

    I understand the desire to just say, "forward data to this object and return me the results." But depending on how it's implemented it could be a boon or a footgun. The obvious direction of pointing to "this" object using a gpointer don't work very well in a diagram-based language.

    posted in technical issues read more
  • jancsika

    Related-- one mechanism that would be nice is the ability to have a singleton as part of an abstraction-based library. For example-- perhaps you want an abstraction that forwards messages to and from a sequencer, and you want the sequencer itself to be part of the abstraction. There's no easy way to do that.

    As a result users generally just put the singleton thing-- array, text object, etc.-- in the main patch, adjacent to the object chain that reads and writes the thing.

    posted in technical issues read more
  • jancsika

    I'm referring to a general problem which currently has no general solution in Max or Pd. Maybe other dataflow environments have found a solution.

    As is often the case with Pd, it's not ergonomic. But it does generalize. You can dispatch arbitrary pd messages to and from any stateful object or abstraction using this technique.

    You can probably also use abstractions to wrap the sends/receives in order to hide the ugly $0 passing.

    Hmm, no, the point is to decouple the output from one and only one path.

    It decouples the output of your state machine from one and only one path. You get N paths where N is the number of abstraction instances you use to, say, implement the Supercollider state machine thingy you linked to. (Just to clarify-- each abstraction only generates output when a message gets sent to its own inlet.)

    If you're thinking that you now want each abstraction to dynamically output to different paths, either I don't understand what you're trying to do or you are overengineering your solution.

    posted in technical issues read more
  • jancsika

    @Boran-Robert There is moonlib/mknob and I believe flatspace/knob in Purr Data, which aims to be compatible with most of what shipped with Pd Extended.

    Probably the moonlib one is available in Pd Vanilla, too.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!