Persistent Mutable Dictionary for exposing values in subpatches to midi/gui/osc

I’m trying to create a patch which can load configuration of midi/elementa/osc changes and route them to my patches for fun knob twiddling experimentation. The patch has a learn button which takes the currently moving midi and adds it to the dictionary which is used to feed the data to the exposed values.

sebescudie has helped me out to create the mutable dictionary from which I can add data to from around the patch, I’m now saving the dictionary to XML, and when the patch loads I’d like the dictionary to be loaded so that the saved configuration repopulates the correct midi channel assignments back out.

So far this is working pretty well, but the patch is getting pretty messy as I try to clean up things, like when assignments are renamed, or removed, and getting some undesired behaviour.

My patching is getting pretty messy and I’d love to colaborate with someone to clean it up as I think it could be quite useful once it’s running nicely.

Anyone interested in colaborating on it?

Things that are left:

  • Update lables for sliders so they represent what
  • Write XML from exposed value nodes when learn banged
  • Remove dictionary items when assignments changed
  • Share the dictionary into the ExposedValues subpatch so these can be inserted into patches to control them.

Mutable Persistent Dictionary with Elementa (23.5 KB)

Not sure If I’m pointing you to the right direction, but have you tried using @dottore’s Model-Runtime-Editor pattern ?

It basically allows you to have a model representing the data your application uses and to store snapshots of it. You might or might not even want to use a GUI, it’s all explained there :)

Nice, thanks for that!

Hi, i think in theory you need kind of singleton approach, sadly i’m not sure how to implement IoC:

So idea is next you create a record with you data type, i would call it a MappingModel:

public string MidiAddress {get;set;} (pad)
public string OscAddress {get;set;} (pad)
public string ReciveAddress {get;set} (pad)

Then you create something called Manager like MappingManager or engine or whatever

public Spread<MappingModel> Mappings {get;set;} (Pad)

Then you need a Singleton:

    public class MappingsLocator
        private static MappingManager mappingManager;
        public static MappingManager MappingManager 
                if (mappingManager== null)
                    mappingManager= new MappingManager();
                return mappingManager;

So then you can use that in Send or Receive node to get your collection in whatever place you want.
In manager you implement stuff like SetMapping(string oscAddress) etc…
However i’m not yet sure where to store values, and need to test this stuff as gamma patch

Yeah, I would image there are lots of people that would find a comprehensive “signal router” quite handy, I’m forever midimapping and using osc in things like madmapper, but I’m forever cutting and pasting from my old patches for midi control, osc etc.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.