controlling Numerology preset changes with a monome 64

[adamj]

Any other Numerology users have a monome? I am controlling Numerology preset changes with my monome. It's pretty sweet :)

More info and the needed files are here: http://compusition.com/web/news/2009/01/07

[jim]

Very interesting -- I was just talking about the monome with a friend of mine yesterday. I'll keep the "assigning preset changes to MIDI issue" on my "look into it" list....

Cheers,
Jim

[amsonx]

Any other Numerology users have a monome?

I' dont have a monome but i play with my Padkontrol and Monomulator to control MLR.

i'll like try your patch via Monomulator so if you can you tell me the prefix of your max patch i can try to use it with monomulator
(sorry for my terrible english)

[adamj]

I'll keep the "assigning preset changes to MIDI issue" on my "look into it" list....


Do you mean "assigning preset changes to OSC issue"? I am already using MIDI to control presets...

For me, the interesting detail that came out of this was how to get feedback on when preset changes actually occur (i.e. respecting preset quantization). I want to know exactly what preset is playing at any given moment by looking at the monome, so I couldn't just light up the button as soon as I press it.

The ProgChange module is great for this purpose. If we want to support preset changes with "pure OSC" I'd probably still use a ProgChange and connect it to an OSC output module, since the ProgChange supports sending a program number when a preset goes active.

[adamj]

i'll like try your patch via Monomulator so if you can you tell me the prefix of your max patch i can try to use it with monomulator

Yeah, the prefix is /numerology and I'm using the default monome ports (8000 in, 8080 out).

Let me know if it works out. I'll help if I can, it would be cool to have this work with other pad input surfaces.

[jim]

Do you mean "assigning preset changes to OSC issue"? I am already using MIDI to control presets...

No -- You used to be able to route prog changes to a stack and just have it respond automatically (ProgChg 1 == preset 1, ProgChg 2 == Preset 2), etc. The current system is more flexible, but more tedious to setup....

For me, the interesting detail that came out of this was how to get feedback on when preset changes actually occur (i.e. respecting preset quantization). I want to know exactly what preset is playing at any given moment by looking at the monome, so I couldn't just light up the button as soon as I press it.

The ProgChange module is great for this purpose. If we want to support preset changes with "pure OSC" I'd probably still use a ProgChange and connect it to an OSC output module, since the ProgChange supports sending a program number when a preset goes active.

That is interesting, I'll have to keep that in mind...

Cheers,
Jim

[adamj]

No -- You used to be able to route prog changes to a stack and just have it respond automatically (ProgChg 1 == preset 1, ProgChg 2 == Preset 2), etc. The current system is more flexible, but more tedious to setup....


I see. I think the flexibility is good, but it does present a bit of a usability problem in this case.

The way it used to work, if I reordered the presets, would it always send ProgChg 1 to the preset listed first (even if it's named "Preset 2")? That would be nice for organization purposes, and allow for seamless duplication/creation of presets on the fly.

But there's this added problem that I'm using the ProgChg module to send feedback indicating the current active preset. Even if things worked like they used to, I'd have issues interfacing with the monome because as I reorder presets or duplicate new ones, those ProgChg modules will not be sending the right values until I manually update them.

Hmmm, feature request idea: There could be a rack-level option to both send and receive program change messages based on the current preset ordering. Then it would be a snap to control presets with an alternate interface. If that option is not enabled, it could work like it does today. Based on my experience hooking things up to the monome, I'd want to control what channel the rack uses for these program change messages.