Hello,
Maybe somebody will find the attached (simple) abstraction useful. I often have to trigger a single gemhead on, and everything else off. This is the best way that I have found to do it is far... If somebody thinks there is a better way, I'd be curious to hear of it.
I have begun to find that abstractions like this save a lot of time in the long run. The main thing a VJ interface has to do, after all, is let me turn various GEMHEADS on/off on the fly, so as simple as it is, it's the basis of doing live visuals for me (combined with key messages, and midictl messages).
The test patch demonstrates the abstraction.
~David
Hallo, David Powers hat gesagt: // David Powers wrote:
Maybe somebody will find the attached (simple) abstraction useful. I often have to trigger a single gemhead on, and everything else off. This is the best way that I have found to do it is far... If somebody thinks there is a better way, I'd be curious to hear of it.
It's not as known as it should be, but one can write a float to a table without [tabwrite] as well: Just send a message with the starting index and the values to write at that and after it to a sender, that is named the same as the table.
So you could replace the [tabset] with [s $0-array] if you add a zero to the incoming list of zeros. Actually sending [const 0( to [s $0-array] is even better in that case.
Attached is an alternative approach to the task of switching on gemheads exclusively. I named it [exclusive], it's very simple and can be made to work for any number of gemheads. It involves a bit more patching and typing than your solution, though.
Frank Barknecht _ ______footils.org_ __goto10.org__
Cool. I was struggling with a mutex switch until Frank put me right with a diagonal message matrix. I like the use of the array, but I cant help thinking, is the intermediate storage really needed? Couldn't it be done in two operations, zero everything and then just route the 1 to the channel that should be on?
On Thu, 25 May 2006 15:01:16 -0500 "David Powers" cyborgk@gmail.com wrote:
Hello,
Maybe somebody will find the attached (simple) abstraction useful. I often have to trigger a single gemhead on, and everything else off. This is the best way that I have found to do it is far... If somebody thinks there is a better way, I'd be curious to hear of it.
I have begun to find that abstractions like this save a lot of time in the long run. The main thing a VJ interface has to do, after all, is let me turn various GEMHEADS on/off on the fly, so as simple as it is, it's the basis of doing live visuals for me (combined with key messages, and midictl messages).
The test patch demonstrates the abstraction.
~David
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Cool. I was struggling with a mutex switch until Frank put me right with a diagonal message matrix. I like the use of the array, but I cant help thinking, is the intermediate storage really needed? Couldn't it be done in two operations, zero everything and then just route the 1 to the channel that should be on?
This would work as well, e.g. as in attached construct. You can test with the previous patch by David.
Frank Barknecht _ ______footils.org_ __goto10.org__
The other approaches are interesting too - for the way I patch things though, I do think mine's quicker... ie. with this abstraction I don't have to do any typing. I like the new version too, although it would have taken me longer to debug and correctly deploy Frank's version.
The arrays may be unnecessary in one sense, and yet as someone with a little programming background, it's quicker for me to conceptualize a design that uses an array. If I went for Frank's approach I'm sure it would have taken me twice as long (but we know Frank is the guru when it comes to using lists!). I see how helpful lists are, but I haven't 100% internalized the list operations and all the list-abs that are available, as opposed to other PD objects.\
Thanks for sharing, everyone.
~David
On 5/25/06, Frank Barknecht fbar@footils.org wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Cool. I was struggling with a mutex switch until Frank put me right with a diagonal message matrix. I like the use of the array, but I cant help thinking, is the intermediate storage really needed? Couldn't it be done in two operations, zero everything and then just route the 1 to the channel that should be on?
This would work as well, e.g. as in attached construct. You can test with the previous patch by David.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, David Powers hat gesagt: // David Powers wrote:
The arrays may be unnecessary in one sense, and yet as someone with a little programming background, it's quicker for me to conceptualize a design that uses an array. If I went for Frank's approach I'm sure it would have taken me twice as long (but we know Frank is the guru when it comes to using lists!). I see how helpful lists are, but I haven't 100% internalized the list operations and all the list-abs that are available, as opposed to other PD objects.\
One should prefer your array-based solution over the list-based one for speed reasons, if it matters. The list-based switch has to build new lists everytime you change the setting, which is much slower than writing a new value to an array and reading it out with tabdump.
Frank Barknecht _ ______footils.org_ __goto10.org__
I use sends and receives to create this behavior.
See attached patch.
Tom
----- Original Message ----- From: "padawan12" padawan12@obiwannabe.co.uk To: pd-list@iem.at Sent: Friday, May 26, 2006 6:24 AM Subject: Re: [PD] switch16 abstraction
Cool. I was struggling with a mutex switch until Frank put me right with a diagonal message matrix. I like the use of the array, but I cant help thinking, is the intermediate storage really needed? Couldn't it be done in two operations, zero everything and then just route the 1 to the channel that should be on?
On Thu, 25 May 2006 15:01:16 -0500 "David Powers" cyborgk@gmail.com wrote:
Hello,
Maybe somebody will find the attached (simple) abstraction useful. I often have to trigger a single gemhead on, and everything else off. This is the best way that I have found to do it is far... If somebody thinks there is a better way, I'd be curious to hear of it.
I have begun to find that abstractions like this save a lot of time in the long run. The main thing a VJ interface has to do, after all, is let me turn various GEMHEADS on/off on the fly, so as simple as it is, it's the basis of doing live visuals for me (combined with key messages, and midictl messages).
The test patch demonstrates the abstraction.
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list