hi all, i've just created a little sequencer abstraction. please look at here:
http://xaero.ath.cx:2005/pd/seq16/
i hope you like it, and improve it... enjoy! :) (sorry for the "dirty" style, but this is one of my first patches)
Suggestion for PD: would be great to see in pd's next release, an UI component that act as a data matrix (think to a Vradio-array, or toggle array) that simplify this dirty work...
Problem: i can't use toggles in my system, because i used to send bangs to read UI-controls's values (which aren't connected to any wire). while radios and sliders react to bang sending their value, the toggle change its state and doesn't send anything. :(
Hallo, Federico hat gesagt: // Federico wrote:
hi all, i've just created a little sequencer abstraction. please look at here:
http://xaero.ath.cx:2005/pd/seq16/
i hope you like it, and improve it... enjoy! :) (sorry for the "dirty" style, but this is one of my first patches)
Hey, it's not dirty at all! Very cool patch.
Problem: i can't use toggles in my system, because i used to send bangs to read UI-controls's values (which aren't connected to any wire). while radios and sliders react to bang sending their value, the toggle change its state and doesn't send anything. :(
This can be solved by storing the current value of the toggle into the right inlet of a float object and then banging that float instead. This also would solve, that currently every change to a slider or so directly sends out the changed value to the outlet, although its not its turn yet.
Some other suggestions: Try creating two independent seq16 objects - it doesn't work: Both will interfere with each other. Solution for this: Never use a send or receive inside an abstraction without starting it with "$0".
A third update would be a possibility to save patterns. I may recommend using "Memento" for this, a state saving system I developed. With Memento, you also don't need to use the float stuff I wrote about above as you can get the stored values anytime out of the currently active state. Examples would be my rrad.pattseq.pd patch, which is similar to your patch, or one of the many other sequencers in the rradical collection. See pure-data.sf.net or footils.org for downloads.
And instead of using the normal toggles I'm currently working on using more flexible data structure toggles, btw. See http://footils.org/cms/show/28 for a screenshot of these (rrad.drumseq). The idea there is, to hide bng or radio buttons behind data structures and then use the messages from the IEM-Gui-Objects to set the data structures on top of them. This is really cool, but also a bit hackish and advanced.
Ciao
Frank Barknecht _ ______footils.org__
hello Frank,
i can't use toggles in my system, because i used to send bangs to read UI-controls's values (which aren't connected to any wire). while radios and sliders react to bang sending their value, the toggle change its state and doesn't send anything. :(
This can be solved by storing the current value of the toggle into the right inlet of a float object and then banging that float instead.
you are right... (i didn't think that when i got in trouble)
...but this involves creating: (in addition to the [toggle])
- a [r $0-noteon-X-set] object,
- connected to [f],
- connected to [s $0-noteon-X]
and when developing complex interfaces, this can be time-consuming, and (maybe) cpu-power-consuming.... :) however, i couldn't find a better solution than using send/recv in conjunction with [select 0 1 2 3 ...] to make the sequencer thing... i read something about qlist, but with an array of controls, the send/recv mechanism is mandatory.
This also would solve, that currently every change to a slider or so directly sends out the changed value to the outlet, although its not its turn yet.
yeah, i experienced some cool behaviors playing a synthesizer live with [seq16] running :)))) i can fix this in a future release.
Never use a send or receive inside an abstraction without starting it with "$0".
i know also the $0-thing. yesterday i was reading some old pd-list's messages, and i wasn't sure if $0-symbol works across different subpatches.... btw this can be fixed by searching&replacing seq16 with $0 in seq16.pd (i hope)
A third update would be a possibility to save patterns. I may recommend using "Memento" for this, a state saving system I developed.
[cut]
See http://footils.org/cms/show/28 for a screenshot of these (rrad.drumseq).
awesome! i am downloading pd externals. (this is my first time ;) hope to play with rrad.* as soon as possible...
cheers
Federico
Hallo, Federico hat gesagt: // Federico wrote:
you are right... (i didn't think that when i got in trouble)
...but this involves creating: (in addition to the [toggle])
- a [r $0-noteon-X-set] object,
- connected to [f],
- connected to [s $0-noteon-X]
and when developing complex interfaces, this can be time-consuming, and (maybe) cpu-power-consuming.... :)
Yes, it's tedious. That's why I proposed to use the Memento system, which does all this automatically. See rrad.sseq16 for a very simple example. Basically your data is stored in the state inside an [originator] object under a name: /n1, /n2, /n3 or however you name the objects. Then you can use "get /n1" to make [originator] output the stored value. Using [makefilename /n%d] you can automate this for incoming numbers.
You still need to create the [commun /n? $0] objects and connect them, but this can be automated, too, by using the [commun-builder] as an environment for internal messages, or use something else for this.
You also could just do this once, and reuse your array of commun objects for all patches by doing copy and paste. This also will make you names consistent.
i know also the $0-thing. yesterday i was reading some old pd-list's messages, and i wasn't sure if $0-symbol works across different subpatches....
They work across different subpatches, but not across different abstractions, of course. Subpatches are a full part (almost) of the surrounding patch. Like a person hidden by a curtain, who still hears everything that's said in a room. Abstractions are seperate rooms with concrete walls between each other. You can build doors into the walls: inlets or global sends.
awesome! i am downloading pd externals. (this is my first time ;) hope to play with rrad.* as soon as possible...
You will need a lot of externals, for the Memento system, you'll need Cyclone, especially the [prepend] from Cyclone (iemlib prepend will not work, ggee prepend will lead to crashes) and [fromsymbol]/[tosymbol]. Some abstractions in RRADical also use maxlib, zexy and some other externals like creb etc.. But for Memento itself, only Cyclone and OSC are required, AFAIR.
Ciao
Frank Barknecht _ ______footils.org__
-
Federico -
Frank Barknecht