Sub Patch
  • Hi I am new to the forum and relatively new to Audulus.

    I am trying to understand sub patches and I am having issues with the "File->Import Sub-Patch" command. When I go into a patch and use the import command, it will create a Sub-Patch node but when I double click the Sub-Patch it only contains the default "Input" and "Output" nodes. I would expect to see the patch content from the patch file I selected. Has anyone had this experience? Can you tell me what I am doing wrong?

    I can add nodes into the Sub-Patch window and it works fine after that but, other than copy and paste from another open patch, I am not sure how to reuse existing patches as Sub-Patches.

    Secondly, I noticed that a Sub-Patch has no way of linking to a master of the Sub-Patch. My expectation is that I would want to improve the Sub-Patch and have it be updated in all instances where it has been placed in other patches, once they are opened in Audulus. (Similar in concept in programming languages between a class definition and its multiple object instances.) I understand that this is not the design of Sub-Patch process so I will wait for comments on my post before I wander over to the feature request part of the forum and say something there.
  • Hi Robin, welcome to the forum!

    I just tested the Import Sub-Patch feature and, my apologies, it is broken. I'll fix that with the next release!

    And you are correct, there currently isn't a way to link to other patch files. I'd like to implement that at some point, but it's complex because of various error-cases. For example, it has to handle the case where the linked sub-patch changes in such a way that it isn't compatible with the I/O the referencing patch expects (much like how changing a class definition might break usage of the class).

    Another concern I had about linking patch files is that it makes the documents not self-contained, and thus harder to share. Though I suppose the linked patches could always just be copied in.

    If you have any suggestions about how the linking should work from a user perspective (how error cases should be communicated for example). Please don't hesitate :-)

    cheers
    - Taylor
  • Taylor,

    Thanks for the quick response. Look forward to a future patch to address the issue with the import command.

    I do have an idea on how to implement a Sub-Patch process that should be able to address dependency errors. When a patch is inserted into another patch as a sub-patch, the sub-patch metadata should retain some basic identity information about the source patch like filename and any other internal relevant identifiers or tags. The source patch content is then copied into the sub-patch just like it does now.

    A new process should be implemented where patches that are meant to be sub-patches should be stored in a specific folder or location that can be tracked by Audulus. When a user opens a patch, all the sub-patches within it are scanned and compared to the sub-patches folder for any matches based on filename or other appropriate identifier. When a match is found, Audulus will then compare the version in memory with the one on disk and look for any differences between inputs and outputs. Basically it should check and very that the source patch’s interface is the same as the target. If they are the same, then a deeper comparison can occur and if there is a difference between them, Audulus should prompt the user to offer an update opportunity. Then it would simply recopy the file in again. If the interface is different, then a cautionary warning should be raised because the user’s main patch will break once updated.

    This process should be recursive to handle sub-patches within sub-patches and then just need to route up the various prompts to the user for action.

    This design would eliminate live dependencies on source patches. The linking is soft and will only activate when a source is found in the sub-patches folder. Otherwise, nothing else happens to the patch in memory and maybe a symbol could be on the sub-patch UI element indicating that its source is missing.

    What I am not sure is if it is possible to do some form of type or range checking during the interface comparison of each input/output element. That could also catch level range mismatches. Perhaps all patch inputs and outputs could contain some metadata about their min/max ranges?

    Anyhow, this should eliminate dependency errors and offer a way to proliferate patch reuse.

    Robin Benjamins
  • Taylor,

    A little more thoughts on the above idea for linking...

    When the situation comes up where the interface is altered (differences in the sub-patch interface inputs and outputs), The reaction in the containing patch, when missing inputs or outputs from a sub-patch are encountered, should be to just deleted the connecting patch cords. Similar to the behavior when a user deletes a node.

    The other thought is that a user can "lock" a sub-patch from the source scanning process which would prevent accidental changes and would also improve scanning and comparison performance by skipping sub-patchs that are locked. This would be handy when sub-patches contain other sub-patches.

    And when an update is permitted but the user does not like the result, I would image the undo process could easily resolve that situation.

    If this works with good reliability and the least amount of confusion and errors for the user, it should allow the community to grow a lot of shareable sub-patches or core modules suitable for beginners and experts. A kind of Audulus app-store concept for digital modular synthesis.

    Robin Benjamins
  • Hey Robin,

    I've fixed the import command in version 2.5 (which I just submitted to Apple).

    I really like your soft-linking idea. We could use modification dates on the files to determine if the linked patch needs to be scanned for changes. The "lock" command is a good point. Perhaps another command to quickly copy in the linked patch would be useful.

    And yes the undo system should handle backing out any changes.

    I especially like this soft-linking approach because its built on top of the existing code, rather than replacing it :-)

    cheers
    - Taylor
  • Taylor,

    Looking forward to the 2.5 version. And glad some of my suggestions were helpful in the design ideas for soft-linking.

    BTW, if you need any help with beta testing of new features or regression testing I would love to help with that. Let me know.

    Robin Benjamins
  • @Taylor, yep the sub-patch import fix has been verified. Thanks!
  • @robinbenjamins, great! You're welcome.