Ok...
Once again, thanks a lot Frank!
We are getting there
So, here's the thing!
I think the solution lies within the attachments Frank sent! Just don't know
how to connect it!!
1st - In the "toggle-with-memory.pd" there is a great principle I need! The OFF
only goes off on a ON!
Now... how can we split the bangs so that I only trigger an OFF when I
want to!?
Besides, as Mathieu said (thanks a lot Mathieu), the [urn] is, for this case,
better than the random. Great, because I didn't even new about [urn]'s
existence.
2nd - However, in "flipper.pd", the way the values are stored is better because
it allows several 1's and (obviously) several 0's (on/off).
3rd - Despite the [urn] being better because it doesn't repeat a number within
the amount it counts through, it would then need the same [select] system Frank
used, but not just for the OFF, also for the ON!
Imagine this:
the 18 slots are on.
through the [select] mode, we randomly turn off the 8,3,18
when we re-run the ON bang, it will have those 3 available
again!
so it will have to select one of those before re-triggering one
already on!
Do I sound insane!?
Can you help me with it!?
Thanks guys!
On 17 Aug 2010, at 17:28, Frank Barknecht wrote:
Hi João,
On Tue, Aug 17, 2010 at 04:30:00PM +0100, João de Brito Rocha Reis Vidigal
wrote:
> Here's what I wanna do:
>
> I have 18 slot for audio and video to play. There can be one playing, none or
> even um to the 18.
> These slots are to be triggered randomly.
> Is there a possibility of storing the ID of the slots already triggered? Like
> a list? The thing is that if it is a list it would have to have a variable
> number of floats (wouldn't it?).
> Why do I need this? Because after triggering a random slot ON I want to
> trigger a random slot OFF. So, I have to know what are the slots triggered on
> in order to trigger one of these OFF and not one 18. Otherwise I could end up
> triggering off a slot that was never on!
> As well I need to know witch ones are OFF to randomly select and turn one on.
A brute-force approach to your problem is attached: It uses [select] to
re-trigger the random selection if you get a slot-value that already is off.
If instead you get a usable slot-value, it stores this in a [f] object
by using the cold, right inlet, so it can be switched off later, then
also updates the [select] via its right inlet to watch for the new "ON"
slot.
There is a small risk to get a lot of the same values from [random] but
this is very, very unlikely.
You should remember the
[t f b]
\/
/\
[f ]
idiom to delay the output of a float value by one execution step. It's
often useful, and also the use of [select] to filter out unwanted
values.
You can also do all this without storing the OFF value by transferring
the logic of switching off or on into your "slot" abstractions. The
c_tgl.pd abstractions shows how to do that. It compares an incoming
slot-number with [== $1] where $1 is the slot-id passed as argument. It
has a global receiver in it to simplify patching a bit.
Ciao
--
Frank
<toggle-with-memory.pd><c_tgl.pd>_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
