[PD] a multislider GUI as abstraction

[Raphaël Ilias]

Hello,

I think this discussion is moving to a general debate... or a troll :-(
about external vs. abstraction
Anyway, I'm interested in this not-so-childish debate, even if I might not
have the skills to give some arguments (like on performance), and that I
think it's more a personal matter at the end.

However, I do agree with Cyrille that shared abstractions may be good
because
- they are patched in "pd" which is, for sure and at least the "common
language of the pd users".
- they can spread and teach clever or elegant ways of patching
- they can provide ways of faster patching when well standardized (I'm
thinking for example to "list-abs")


2016-06-27 17:41 GMT+02:00 Alexandre Torres Porres <porres at gmail.com>:

> Yeah, most of your points against externals sounds a bit like "they need
> to be maintained and that takes effort", I know... but I don't think that's
> a disadvantage of an external. If no one is willing to do it, that's
> another problem...
>
> > OK,sometimes, externals can be faster. And in sometimes, it matter.
> > Also, sometimes, externals can be more flexible
>
> Yes, those are my points regarding externals. But I say they're always
> more flexible. Abstractions' functionalities are very limited and not
> flexible at all.
>

Yes, I absolutely don't know how to program something like [comport] in an
abstraction ;-)


>
> > Do you think of a fact that would lead to reprogram it to an external?
>
> I was pinching general points for externals in general. Nonetheless,
> specifically about this one, I can think of many advantages. First, when I
> try to open it in vanilla, I get *658* lines in the Pd window of couldn't
> create errors. And it'd be more if I didn't have one of the dependencies,
> which is cyclone... but it does need over 10 external libraries, and I
> don't want them all...
>

> So, first thing I have to say is... if external libraries are bad and a
> pain... why does this one needs so many of them? If this was a vanilla
> abstraction I could understand the point... but it's more of a Pd-Extended
> abstraction.
>

You could also have re-read my email before opening the patch... I warned
that it had a lot of dependencies and that it was first written with
Pd-Extended.
However, as Roman pointed out, and that was also my question, half of the
externals used here could be replaced by... abstractions ! If some users
cared about having a good-standardized library of externals that could be
way more easy to maintain because, once again, I think most users don't
know C, but all of them know Pd, at least a bit of it.
The reason the file is so big, is that I replaced some of my own
abstraction by the same but in a subpatch, which makes redundant code... So
that's antoher point for abstractions.


>
> And thus I tried it in Pd-Extended 0.42-5, the one I use, but I still
> can't get it to work. Not sure how better it is in 0.43 (which I'm not
> installing as it always screws things up in my system) - but it seems it
> needs even more not included abstractions such as 's.mmb'
>

Yes, as I said, 's.mmb' is not necessary to test this [ph_msl] abstraction.
I should have removed it, sorry.


>
> So, regarding this particular example, this is a very classic one where
> it's quite kludgy (with so many dependencies) that I can't even open.
>

The example was short because you could'nt explore so now we go back to
general ideas and opinions ?...
I'd be more interested in knowing what would be a good multislider GUI, and
how it could be done (without learning C !?)


>
> Now, if cyclone had a multislider object, cloned from max msp ,and then if
> you have cyclone (one of the libraries this abstraction needs), all you had
> to do is call it... and, in this case (as I pointed when I entered this
> thread) it'd have many more functionalites.
>

Could you be precise ? What "many more functionalies" ? I am really curious
here.. that could be a challenge.


>
> I understand many of the arguments if this was a vanilla abstraction, but
> it is not. And even if it were, GUI is something that I think is
> particularly better to have an external in order to potentialize its
> interface purposes.
>
> From reading the email, seems there are attempts to solve many of the
> issues like right clicking and getting into a properties window, which I
> think it's impressive and I'd like to see that as I still cannot quite
> grasp how it'd be possible. Nonetheless, some GUI functionalities are still
> only possible with an external.
>

the properties windows is done with [iemguts/propertybang] and [vis 1(
method to a [pd-$0-properties] subpatch containing the properties windows
and all its GUI (size, number of sliders, colors...)


>
> > - as you know, i'm using a very limited range of externals
> > (pmpd / Gem and very few other).
>
> So it doesn't seem likely you were able to check this one before
> discussing about it, or could you?
>
> > - they are faster to develop (human time is more expensive than cpu
> time)
>
> It doesn't seem, by looking at all the dependencies and size of the patch,
> plus the research on how to solve many of the existing problems that it
> took little time to do this. And it seems the only issue for not having
> done this in C or whatever is the lack of knowledge in programming skills.
>

Yes that is exactly what I said when proposing this abstraction, I am
personally interested in this way of "contributing" to pd by sharing
abstractions because I lack of the C knowledge and I lack of the desire of
learning C.
And because I don't want to wait for someone to program in C an external
that does a good multislider GUI, I tried to do this as an abstraction (and
once it is set up, I think it's a quite handy and functional GUI, at least
I did use in live performances even though it's not a proper program test
procedure...).


>
> > - lot's of externals are deprecated
>
> I agree, that's why I don't like the idea of an abstraction that needs
> over 10 library dependencies and over 20 externals, many of which are
> currently unmaintained...
>
> Anyway, making a decent GUI as an abstraction is not a trivial thing at
> all, as this example points out. I agree with Raphaël that there are many
> problems with GUI in Pd, I wish there were more... it's very limited, and
> being a visual graphic environment, that's a bit contrasting.
>

I agree with you.
I think improving the "form" of Pd could make it a more useful tool. A
diagram design involves as much "graphic/drawing" intelligence as it needs
to mean something in a computer-language.
(At least, the few months I tried Max/MSP after 4 years with Pd, that's
what I felt, that my way patching was more clear because of some graphic
features, like segmented patchchords... but I still resist to use MAX)


>
> > don't use pd if you need lot's of performance, use pd if you
> > want to develop fast. Use C from start to end for performance.
>
> I use Pd cause I'm a musician and I'm not a programmer, and I just want an
> efficient and convenient patching environment.
>
> > i think abstraction are preferable when possible because
>
> I do offer a couple of abstractions that are vanilla patches, and I don't
> think they'd gain anything being externals, I agree with the general idea
> and common sense that sometimes it'll do... it'd be more convenient, and
> etc...
>
> That is why I say this discussion will rely mostly in personal opinions
> and subjectivities, sometimes disagreements will be just subtle... so I
> never pointed "externals are always better, never do abstractions, just
> externals".
>
> But I did jump in here to say it'd be so much better if this was just a
> compiled external in cyclone... and I do have a pretty strong point for
> that!  To respond to your quote, in this case, I don't consider it
> convenient or preferable in this case.
>

I agree with that. It would be probably more : distributable, efficient,
maintainable, easy to improve... if it was written in C instead on relying
on dozen of externals that may be discontinued.
However, I think that the vast majority of pd users don't know C, don't
want to learn it... but would be glad to contribute to the improvement of
Pd as a "efficient and convenient patching environment".

I think that abstractions are messy but a good way to experiment patching
techniques. I have the impression that an object like "clone" (that I
haven't tested yet but read about it) is a standardization/formalization in
C of what a lot of users had done practically with dynamic-patching.

I am still interested to know if this [ph_msl] could be an alternative to
wait that generous and clever developers make and provide a nicely designed
external multislider GUI ?
... as this one features :
- mouse/key user input close to iemGUIs (alt-click for smaller step,
shift-click for relative mode)
- size / colors / number of sliders parameters
--> that can be set by message and through a GUI you show by 'right-click >
Properties'
--> that can be stored as the instance arguments, so be saved with parent
patch

I think this abstraction dependencies could easily be reduced to :
[iemguts/receivecanvas]
[iemguts/canvasargs]
[iemguts/propertybang]
[iemgui/iem_event]
[hcs/colorpanel]

Best regards,

Raphaël
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160627/5368443c/attachment-0001.html>