• seb-harmonik.ar

    updated to 0.51-3 https://github.com/sebshader/pdnext/releases/tag/0.51-3
    used updated (fixed) tk with no-scrollbar and disabled-help-menu-items fixes on osx, in addition to the font and permissions fixes from pd 0.51-3 (and the new expr functions)

    posted in news read more
  • seb-harmonik.ar

    @ingox or file feature requests on github..

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

    @ddw_music said:

    One way that this could be improved:

    • Pd could recommend externals be placed under a specific location. (Actually, here, you could follow SuperCollider's lead and have a system-wide location and a user-specific location.)

    well, pd does now prompt/recommend a directory for installing externals (e.g. ~/Documents/Pd). It just so happens that the path isn't in the static paths. It was better when there were just 2 standard library locations: 1 for system-wide libraries and 1 for user-specific libraries (e.g. /Library/Pd and ~/Library/Pd on osx). This is still technically the case, they're just not the directories that pd prompts the user to install externals to. (though they are installed there by default) http://msp.ucsd.edu/Pd_documentation/x4.htm#s2.1

    imo prompting the user to create ~/Documents/Pd and install externals there is a mistake

    • Per patch file, keep a list of which locations have provided externals or abstractions.

    the declare help file does say "WARNING: as of version 0.47, "declare -path" and "declare -stdpath" inside abstractions take effect only within those abstractions. If Pd's compatibility version is set to 0.46 or earlier the old (buggy) behavior takes effect."
    perhaps this could be extended to libraries too

    • If there is a binary library in the access path, load it automatically. Do not make the user distinguish between lib and path.

    I agree that if someone specifies "-lib" it should work for multi-object, abstraction, and single-object libraries. However there should be cases for adding to a path without it being a library imo.
    maybe the solution is a general "import" object for libraries like extended used to have, since [declare] seems to be designed to refer to specific binaries and paths without any further method of abstraction.

    • If it's the first time this subdirectory provided an object to this patch file, print a message in the console (help the user not overlook the dependency).

    I don't think this is a good idea. It would clog up the console. maybe there could be some kind of helper object or something in [pdcontrol] or [declare] that gets a list of all of the library or external dependencies of a patch when the user needs them. (or maybe some external would be better).

    • Have a menu option to print a list of dependencies. (If the list of external subdirectories is saved in the patch, this is easy.)

    The whole idea of using [declare] is to be able to understand a patch's dependencies just by opening it. Of course when people develop with libraries loaded into their startup path instead of using [declare] or [libraryname/objectname], that doesn't work. But if people actually used [import] or something instead this would be unnecessary

    For me, the sticking points are that the search is non-recursive (this design decision, frankly, baffles me, I could not disagree with it more strongly) and that the user is expected to know which external packs provide a single-binary library.

    I think it's good that libraries aren't searched recursively. This allows the maintainer/developer full control of loading resources, and doesn't waste time searching potentially large non-object resource directories in a library every time an object is loaded.

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

    @oid well abstractions are good for understanding the language and often good for quick development. However, c externals are almost always far more efficient/fast if the same general algorithm is used. Just for the simplest example, getting a "float" in pd requires a few function calls: sending a "bang" message to an object that calls its outlet function, which finds the connection and calls the "bang" method for float which then calls the outlet function after accessing the data itself (the actual float value). in c all that would be is 1 memory lookup, and would require the memory of just 1 float instead of an entire pd object. And that isn't even counting all of the extra space and processing it takes to manage the object and class.
    You can do a lot in vanilla but there are definitely things that are way easier to do even in c. A good example is any list processing, or any searching or sorting algorithm, or any manipulations of more complex data structures.
    Personally I like to use pd for signal-graphs and some message glue, with lua doing the structure and sequencing (with pdlua) and c doing the complex low-level or data structure stuff.

    you should be able to make almost anything in vanilla, but for practical use it makes more sense to use compiled externals where possible. I wouldn't necessarily call the gains "purely academic" anyways.
    of course you also have to consider how many dependencies you want your patches to rely on..

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

    @ingox it's not exactly the same bc the management of the dsp graph is not exactly analogous to the "receive list" of the send symbol

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

    @jameslo yeah, and also it could change based on the implementation. Definitely should be avoided, but it seems possible.

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

    @jameslo test2.pd
    [receive~] and all of the dsp objects connected to it are created before [send~] and all of the dsp objects connected to it.

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

    @jameslo I didn't actually go through the code but just in the simple tests I did if you create the entirety of the graph with the [receive~] (including the [receive~]) before the graph with the [send~] (including the [send~]) then it appears to be in the right sort-order.

    however when I deleted the [send~] and [receive~] afterwards I couldn't get it back in the right order when I recreated them no matter the order.. maybe something to do with [send~] being at the bottom of a graph and [receive~] being at the top of one or something.

    might have a look through the source later and try to figure it out for real.
    I would think that this is dependent on the implementation and not guaranteed to stay the same if the implementation changes significantly tho..
    Ideally all [send~] graphs would be sorted before their corresponding [receive~] graphs..

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

    @jameslo i haven't tested it but it might be the case that if you make sure to create [receive~] after [send~] that there will be no latency, (unless the [receive~] is in part of the graph that leads to [send~]). You might have to create the entire graph the [recieve~] is part of after creating the entire graph the [send~] is part of, I'm not sure..

    edit: after testing I was not able to get that to work :disappointed:
    edit2: after further testing it seems like if I create the graph with the [receive~] first it gets sorted last, but not if I delete the [receive~] and recreate it afterwards

    so there isn't always latency, it depends on how the dsp graph is sorted. If the [recieve~] is sorted earlier in the graph before the [send~], as in the case of feedback, then there will be a block delay since [recieve~] will process the shared buffer's samples before [send~] has had a chance to write to the shared buffer. (so [recieve~] will only get the samples written in the current block by [send~] in the next block, creating a block delay.)

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

    this person made one with raspberry pi

    posted in I/O hardware diyread more

Internal error.

Oops! Looks like something went wrong!