yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional
abstractions. that
was the big flaw of the DIY library i did, that the function of
the
abstractions was tied in with the gui component. i did it that
way because
i didn't want to clutter the namespace with too many
abstractions, and the
thought of one abstraction for function, and then a different
one for GUI
was not appealing at the time.
but now, i think that is the only way to go. like, as you said,
for
polyphony. and then also for the many many cases in which you'd
want to
build your own gui for custom control.
i do think you guys have got a really really strong system there
with
rjlib. but i was just saying that without the gui stuff, it
doesn't exactly
fit into being that 'all purpose building blocks' library that
we are
discussing.
This is where the pd-mtl convention makes so much sense ...
Core functionality is made into patches with an underscore at the end of the name and the regular name is just a gui wrapper around it. I've started using the approach in the rc-patches and, as Frank said before, it makes building larger gui objects much simpler. The right inlet takes all the control whenever possible using name messages.
So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with SSSAD. So if you want SSSAD you use the gui.
Dan Wilcox danomatika.com robotcowboy.com
Hallo, danomatika hat gesagt: // danomatika wrote:
So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with SSSAD. So if you want SSSAD you use the gui.
I wouldn't put the sssad objects in the version with GUI. IMO It's more useful to have them in the engine objects, e.g. for polyphony.
Frank
Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with SSSAD. So if you want SSSAD you use the gui.
I wouldn't put the sssad objects in the version with GUI. IMO It's more useful to have them in the engine objects, e.g. for polyphony.
could you explain the polyphony example?
doesn't each voice have the same parameter, coming from the gui?
in my experience it's best to save the state right at the interface, i don't see the point of saving state deep in the core.
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
could you explain the polyphony example?
doesn't each voice have the same parameter, coming from the gui?
I might want to save settings even though I didn't use a GUI to set them. Settings don't necessarily come from a GUI.
For example say I use an algorithm to generate settings, or I may write my settings into a textfile or a message box - there also is no GUI involved. Settings in Pd however all are manipulated by sending messages, even GUIs are just a way to generate a message. So the way to save state in Pd IMO is to intercept message, not to watch GUI elements.
In regard to polyphony, it's pretty common to duplicate a synth voice many times, manually or using e.g. polypoly or rjlib's u_makepoly. There is no need to have a GUI in those hidden objects, but I still need to access their parameters to set them. So what I need is a way to peek into the abstraction and eavesdrop their messages.
In rjlib that peeping hole is the rightmost inlet. [sssad] is used in a wrapper u_dispatch at that inlet that also dispatches messages coming in to local senders. So the abstractions all know their state even though most of them don't have a GUI. If I want a GUI, I just make one that produces messages for the control inlet.
Maybe some OO programming language experts can say smart things about how this is related to a Model-View-Controller paradigm, where the GUI elements constitute one of many possible Views, the [textfile] is a Model and [sssad] is the controller but I'm not good at this stuff.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
so are we going to go ahead with this?
does anyone want to volunteer to set up a wiki? i'm terrible at any of that sort of thing.