well, lets see if we can get this to a closure
> So, basically you are saying it is less trouble
> to make an external than an abstraction?
Nope, never said it. Not sure why you took it that way. Maybe because I mentioned "efficiency". But that was supposed to mean computer efficiency, and as a response to what I thought was a general question about compiled classes vs abstractions. Not that the discussion was really about that, and, more importantly, not that is was my point at all, as I clearly stated and then shifted to my point after that...
I didn't even feel like moving the discussion that way, that's why I tried not to do it and stick to my point, by the way.
> I give you an abstraction and you say you're
> still looking for the external?
No no no. I'm not looking for no external. I already know about the external, and I even mentioned about it in my sencond message on this thread, when I said I was hoping there'd be a "[peakenv~] like object" in Vanilla. And then I pointed it could come as a feature in a probable update of [env~].
I've been using [peakenv~] and mostly [prvu~], I think they're great.
> Agreed, but I still have difficulties in understanding> why you desperately need it to be a compiled class
> (I am certainly not against it, though).
I wouldn't say I'm "desperate"... so you don't need to keep having trouble trying to figure me out. Also, I never even said I "need" this to be a compiled class, cause I actually do not. I'm happy to share my point yet again, but please don't misinterpret/misjudge my words.
Once more, my only point is that I think this is an important feature that should come in vanilla objects, it deserves to! Maybe as an extension to [env~], like in a second outlet... that wouldn't hurt... and wouldn't even require a new object. Anyway, that's all there's to it. Nothing more...
I think I'm being very clear and straightforward. Not anyone here thought this was a bad idea too (so it seems), now I'm wondering what is all the commotion about... or does anyone think this is actually a bad idea?
I mean, I seriously wonder what's the deal. Pd Vanilla comes with a very limited set of objects, we all know that. I can get by with that with no problem. I'm just pointing how one little thingy could come into the set, and suddenly things get off track to turn into such a debate. I don't know, I suspect there can be something to it... :)
> Why are abstractions second class citizens in your opinion?
Maybe if I had ever stated that, I could answer you to that question. What you could ask me without putting words in my mouth is: why do I think Peak Level detection should come as a function in a compiled class in Pd Vanilla, when you can do it as an abstraction or when there's a couple of objects in Pd-Extended that'll do it for you.
Well, I think it is such a basic feature that deserves to be out of the box from Pd Vanilla in an object like [env~], and I guess I'm repeating myself...
Thing is I have very little knowledge in C and compiling objects, so doing abstractions is All I do... I think it's great people like me can get by with them... but you know, eventually some stuff will get you thinking "hmm, this could have already been made available out of Vanilla objects..."
Moreover, I mentioned [vu] (a vanilla GUI) in my first message and how it receives peak level, but no vanilla object does that job. That looks like something missing or incomplete in Vanilla. I really hope to see [env~] handling that issue soon.
That'll make my day and think the world is a better place.
Cheers