[PD] a multislider GUI as abstraction

[Alexandre Torres Porres]

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.

> 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.

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'

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.

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.

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.

> - 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.

> - 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.

> 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.

cheers


2016-06-27 7:09 GMT-03:00 cyrille henry <ch at chnry.net>:

> hello,
>
> i'm sorry to jump again on this kind of topic, but it's painful to read a
> mail like that.
>
> Le 26/06/2016 23:31, Alexandre Torres Porres a écrit :
>
>>
>>
>> 2016-06-26 16:35 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at <mailto:
>> zmoelnig at iem.at>>:
>>
>>     for me this sounds a bit like "i'd love to see them as externals
>>
>>
>> totally sound like that :)
>>
>>     *so* they can be included in some library"
>>
>>
>> yeah, also like the idea of having it not as a single separate thing
>>
>
> abstraction vs external did not change anything regarding this matter.
> anyhow, you can create a "useful_abstraction_from_the_mailing_list" folder
> on your computer and it will soon be full of patch. (no more separate thing)
>
>
>
>>     would you care to explain what makes externals superior?
>>
>>
>> I don't think I'm the best one to discuss about the external x
>> abstraction in terms of 'superiority', but yeah, I do like them better, I
>> think they can be designed and work in ways that abstractions just don't
>> (specially GUIs),
>>
>  and it's a common sense they are more efficient.
>
> common sense is sometime wrong.
> - expr is an externals, using it for a big equation is slower than the
> same equation programed as abstraction
> - gui is slow, problem comes from TK, switching from abstraction to
> external will not help
>
>
> anyhow, performance is not really a problem because :
> - You don't need to optimized everything. You have to optimize only the
> bottleneck of your patch, usually it's the audio routine. Blindly
> optimizing the rest is loosing time for no performance gain.
> - 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.
> - as you know, i'm using a very limited range of externals (pmpd / Gem and
> very few other). Even when working with very big patch, no externals could
> solve performance problem I could face.
>
>
> i think abstraction are preferable when possible because :
> - they don't need to be compiled. For example, there is no more windows
> pmpd user because i can't provide binary for this platform. This is very
> sad.
> An other example is when distributing a patch on a CD/SD, it became
> obsolete as soon as osX get a new version.
> - they are faster to develop (human time is more expensive than cpu time)
> - they can be distribute with your patch, even if they are not part of an
> official lib (solving dependency problem)
> - They can be easily customizable by any user. (most pd user never
> compiled anything). Or reuse only part of the abstraction.
> - You can learn a lot about pd programming when analyzing an abstraction
> code written by someone else
> - lot's of externals are deprecated, patch using them became obsolete.
> abstraction are immune to this problem
>
>
> In any way, I guess this discuss will touch known facts and issues and be
> subject to personal preferences.
>
> Personal preference can be irrational, but they can also evolve.
>
> OK,sometimes, externals can be faster. And in sometimes, it matter.
> Also, sometimes, externals can be more flexible. (initbang problem)
>
> But it look like this abstraction did not fall in this 2 categories. Do
> you think of a fact that would lead to reprogram it to an external?
>
> cheers
> c
>
>
>> cheers
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160627/528bcb6d/attachment-0001.html>