Midi controllers and Isadora control panels
-
Dear JSteph,
Controllers send values when they are physically manipulated. This is by design, because if they sent values in response to receiving values from the actors, it is highly likely you'd end up creating a feedback loop that would crash the program.But what you're trying to accomplish is totally doable. Please look at my example patch and the comments within and let us know how you get on.Best Wishes,Mark -
Thanks Mark
Your user actor is helpful to me. I am building an Izzy control panel for my UC33 that will be used in several different stages and this is a quick way to connect the stages and make changes after I know what I really want to do. -
I dear Vanderzee,
I use little "though" actors like this quite frequently... it helps for organization, etc. And, if you minimize them (and turn off the Actor Names, which I always do anyway) they are very small.Best Wishes,Mark -
@Mark.
These thru actors are hugely important to organizing large patches.
How about adding a dynamically typed Node actor the to the toolbox? The ability to insert a Node on any patch cord?
I know this is off topic a bit.. but I have seen this come up as a forum solution a few times. I think if included in the toolbox as a standard actor.. it can be more easily outlined as a best practice. -
@DusX I tend to use a router actor with only one output for these sort of pass-through purposes but I agree that a dedicated actor would be a convenient addition.
-
Hello Mark,
Thank-you very much for the example scenes. They clearly illustrate how I can get this up and running. I previously had a complex mapping of ins and outs from midi to the faders and back that would have, as you you highlighted, ultimately caused feedback.
I mapped a couple of faders using your examples and your schema works like a charm.
I agree with Matthew. While a user actor or a router with one output work well as "pass through", a simple "Null" actor - like in QC or Touch - could be a helpful addition.
In any event, I thank-you again for your input.
Best,
- Justin
-
-
Skulpture, No worries. I have this working but not quite in the manner that I had hoped.
What I was hoping to do would be to have the Midi IN/Midi OUT control in a secondary scene - activated by my INIT scene - and then to be able to simply use the midi-ified control panel to control parameters in subsequent scenes.
What I am doing now, is placing the Midi IN/OUT mapping actor I created in a given scene and connecting it to actors I want to effect. It's slightly less tidy, but it works.
I guess I could use broadcasters and listeners, but I think that gets a bit unwieldy.
Best,
- Justin
-
Hi everybody
_Excuse my english, I'm french_For complex patch, i use Broadcasters and receivers on the same page,and i don't think it is unwieldy, but rather the opposite !I reserve the last hundred number, 900 to 999, and list them in a comment. So i can isolate functions in the patch view.I just think that we have to forget the name, or the idea, Broadcast and Listen, because it is just metaphoric, not real...fypy -
Fypy, I will have a look at this again. Thanks for your comment on the "metaphoric" nature of broadcasting and listening. It is useful and made the communication scholar part of me laugh - "how true", I thought.
I suppose what I could match the CTL numbers to the broadcaster numbers. This would let me map out my Midi controller user actor and the accompanying Control Panel. This way I would not even need to refer back to a legend, just to the controller CTL ids.I wonder how heavy the Broadcast/Listen actors are compared to direct connection.Hmmm. I will report back.- J -
Dear Jsteph,
Note however that there is some overhead with Broadcasters and Listeners. I would not use them to replace links between actors.Best Wishes,Mark -
@Mark
How much overhead is there?
I have used them rather heavily in my SYST3M mixer (http://www.dusxproductions.com/blog/alpha-release/) as a method of making user linkable (via the control panel) modules. In SYST3M I might have as many as 30 broadcast and listen pairs active at one time (if I am running DMX and video together).
What type of overhead/delay might this cause?
I ask because I am reworking the framework in hopes of having it ready for the next Isadora release. -
Dear Mark, i really wonder why you say it is "overhead", and my undersanding of english is not good enough to see what you mean.... I never had problems with this way to do... Maybe it´s because i use Broadcast/listen just for the controller's links, with simple and discrete data flow...
-
Fypy, How many Broadcast/Listen pairs are you working with?
-
jtsteph, about 10 Broadcasters and 20 receivers. Not that mutch... Mark, for me as a french guy in the music business, "overhead" is the way you put microphones above a drummer, or a group of violins, to catch the ambiance ; and the litteral translation is "au-dessus", like "above" is... That is why I don't unserstand...
-
@fypy Mark will mean some extra processing/CPU I think. How much I am not so sure.
-
Dear All,
10 or 20 is no problem. It's when you have 100s that it might start to have an impact.Best Wishes,Mark -
Mark, Are they processed if they are unpaired? For example, if I layout 100 senders but only use 10 receivers will all of the senders still be processed?
-
Hi everybody I was reading the entire discussion, and noticed that we are all using some "tricks" to distribute, or organise, or dispatch signals or datas in our patches. Mark uses user actors builted with one user input connected with one user output, and that's all, to act like a node, Mathew uses router actor with only one output, and it seems as strange as a switch on a single rail, I often use broadcast/listen on same pages, or use delay triggers with 0 seconds delay (look strange, uh ?) Like Mathew and Justin said, I think there is a missing actor... I imagine it like a "Patch" Actor, like in studios, with virtual and "wireless" invisible cables, let start with 128 (!...). On the left, a choice of the number of the inputs (from 0 to 128), and the numerical value of each, and the same for the outputs. No needs to have labels, we can use Comments on the side. And every input using "match property" function. What do you think of it ? fypy
-
"Patchbay" actor could be the proper name...
