Presetmanagement with similar subpatchers in pattrstorage


    Feb 07 2008 | 12:47 pm
    I have a question about strategies how to deal with the following problem:
    If I have a mixer with multiple channelstrips, and lets say each strip
    has its own filter. I would place a channelstrip into a bpatcher by the
    way, but for voices of polyphonic synths/samplers the same problem would
    apply:
    Now what I want, ist o have a single pattrstorage to be shared among the
    multiple strips/voices. As far as I know, if I place a pattrstorage into
    one strip, and duplictate it, I get several independent pattrstorages...
    But I want to acces them like a named coll and share their data across
    multiple instances...
    I always thought naming the patterstorage is ment for that purpose, but
    it isn't... :-(
    The solution I have at the moment is, to writeagain the pattrstorage on
    any change always to disk, and notify the other instances to readagain...
    Any better solutions around ???
    Stefan
    --
    Stefan Tiedje------------x-------
    --_____-----------|--------------
    --(_|_ ----|-----|-----()-------
    -- _|_)----|-----()--------------
    ----------()--------www.ccmix.com

    • Feb 07 2008 | 1:21 pm
      Unless I miss the point about why pattrstorages should be instantiated locally, the suggestion would be to have one globally?
      _
      johan
    • Feb 07 2008 | 1:33 pm
      i think Stefan is looking for a dynamic system for applying specific sets of presets to identical modules.
      these modules can probably have their own set of presets as well as copying the ones of any other moduleand/or having one set of presets from one module being applied to all the other modules.
      right now i could only think about storing individual groups of presets into individual colls via "dump" message ( to pattrstorage) and have have a matrix based routing system from which routes the chosen contents of these colls back to chosen nested pattrstorages ...
      probably a little cumbersome ...
      Quote: jvkr wrote on Thu, 07 February 2008 14:21
      ----------------------------------------------------
      > Unless I miss the point about why pattrstorages should be instantiated locally, the suggestion would be to have one globally?
      >
      > _
      > johan
      ----------------------------------------------------
    • Feb 07 2008 | 1:42 pm
      Now I see.
    • Feb 07 2008 | 2:33 pm
      Ok, Stefan, to make up for my previous stupid remark. This patch makes use of a pattrhub and an actual object performing as a hub. I believe it works.
      _
      johan
    • Feb 08 2008 | 11:40 am
      jvkr schrieb:
      > Ok, Stefan, to make up for my previous stupid remark. This patch
      > makes use of a pattrhub and an actual object performing as a hub. I
      > believe it works.
      Thanks for sharing, it does work. Though I'd probably prefer the
      writeagain/readagain method, as its simpler and more readable in the
      resulting XML files (Yours squeeze all the preset information into a
      single pattr. I doubt it will scale easily into bigger patches).
      I don't mind to have several preset.XML files, as in that scenario the
      way of thinking is also by seperate collections of presets. I just see
      the impossibility to undo or not save a new setting with that method...
      Maybe I have to save them to a temp file, which will in turn make it as
      complex as your solution... ;-)
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com