• oid

    WARNING: There is a bug which tosses pd into an infinite loop under certain circumstances. When tt/pp/uu are run they save the patch they are editing and this saved version will have that object as [tt x x x x] or the like, if it is an abstraction which is used in an open patch every instance of the abstraction will be updated to have that object as [tt x x x x] and they all run [tt] and all try to do the same thing at the same time, pd goes infinite. Will be fixed in a day or two when time permits, until then do not use it on abstractions which are used in open patches!

    No more swapping wires or disconnecting and reconnecting things when you need to get another bang at the start of your trigger.
    output.gif
    Some dynamic patching fun, just rename to the object as required, adjust your arguments to suit and it patches in the new trigger/pack/unpack automatically. This should save some time and headaches. Requires iemguts to use but since it replaces itself with a vanilla object your patches will still be vanilla if the target platform needs vanilla. You can confuse them and get some unexpected (actually logical) results, but easy enough to work around and certainly quicker and easier than the old way. They save your patch everytime you use them, so keep that in mind, could bite you if you forget. If you have not saved the file before using them they will fail, but undo, save, and all is well. Hopefully I finally got all the bugs out.
    pp-tt-uu.zip

    posted in abstract~ read more
  • oid

    @ingox Why not just [$1 $2}? Does [expr] offer anything extra in that case other than increased overhead?

    posted in technical issues read more
  • oid

    @ddw_music said:

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

    I was going to do that as soon as I finish them up since it gives them an actual example of how they work and will not fall victim to my inability to communicate with programmers. They should be finished up and uploaded tonight, just need to give them a once over with fresh eyes to make sure I did not miss anything obvious.

    posted in technical issues read more
  • oid

    @cfry Here is an improved list-apply, it uses [list store] so does not iterate the list, just does the math on each list item individually. As a bonus you can change the function on the fly to most anything. No time for an in depth help file, but this should suffice.

    Edit; this requires at least pd 0.52 for the [list store] [set( message.
    list-apply.pd
    list-apply-help.pd
    Untitled1.png
    Untitled2.png

    posted in technical issues read more
  • oid

    @whale-av said:

    As all 3 objects can contain different functions.

    I knew I was forgetting something obvious. Deleting the connection with the inlet/outlet is the only sane thing here since letting the connection stay will often cause it to be connected to the wrong type, and this is also expected behavior. Thanks for pointing me back in the direction of reality.

    posted in technical issues read more
  • oid

    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.
    output.gif
    But as I am getting ready to upload them I am finding myself stuck on the final details, mainly how to deal with removed outlets/inlets. Should I just delete the connection to that outlet/inlet or should I shift all subsequent connections too accommodate the decreased number or add a shift operator like < or > to specify which direction you shift the cables? I sort of think just let simple logic win, connection stays connected to outlet/inlet # even if you delete it, if you delete outlet 3 the connections too outlet three will now be connected the old outlet 4 since it is now #3 and the old connections to #4 will be connected as well to the new #3, let the user decide after the fact since shift-click cable swapping and deleting is easy enough and adding in shift operators could just confuse things since stacking them could get confusing quickly?

    I also made abstractions for [route] and [select], as of now they just keep the right inlet connected instead of shifting that connection to the left by how ever many new outlets are added. I would like to add the ability to insert and delete outlets to these since it can help to keep patches neater without a whole lot of cable swapping but I can not think of a reasonable way to signify removing or adding an outlet since anything could be a valid argument for [route] and [select]. Open to suggestions here, perhaps just stick with the caps convention of the other objects and accept that it will not work for all situations?

    What is the consensus? Is there one?

    Also, has no one ever made these? They were simple enough and seem obvious, but I can not find such a thing. I really feel like I must be reinventing the wheel.

    posted in technical issues read more
  • oid

    @atux I think the bug here is with your install of pd, not pd in general itself. Works fine for me and should work on even quite old versions of pd.

    posted in technical issues read more
  • oid

    @whale-av said:

    Yes ..... I didn't mean "dynamically create an abstraction".
    It would have been clearer if I had written "dynamically put an abstraction".

    You were clear in what you said, I was just posting when I should have been sleeping so I missed the point and finished it all by rambling about completely irrelevant things.

    posted in technical issues read more
  • oid

    @whale-av said:

    If the sub-patch is even only a little more complex it can be easier to dynamically create a whole abstraction that contains send and receive type objects, as a large quantity of [connect( or [disconnect( messages can spin your head off your neck.

    That is why you just patch it manually, save it and let pd figure out the connect messages for you. Or you use this bit of cleverness.
    https://forum.pdpatchrepo.info/topic/12690/a-patch-to-transforme-patchs-into-a-set-of-building-instruction-video-explanation
    I like doing the connect messages and find them easier than the objects, which is why the objects are in their own messages and the connects all stuck in one, I always screw up the objects and pd's wonky text selecting causes me to screw them up even worse, separate messages helps to limit the damage.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!