bad help file for [output~] in extra / new abstraction suggestion

changed title from bad help file for [output~] in extra to bad help file for [output~] in extra / new abstraction suggestion

Thanks for the report. We definitely need to clean up the help files, including this bug you reported.

As for your replacement-- it looks taller than the current pd-extended [output~] abstraction. Can you give it the same dimensions?

I'm redesigning a new one, as closely related to the old one as possible!

Sounds good.:)

here you go...

also realized that the [output~] found in pd-extended's extra folder is in fsact a copy of [ezoutput~] from pddp (also present in purr-data). Anyway, I worked on the help file as well taking the original one as a template and put some of this information in there!

output.zip

I used the $@ thing in this new version to load the arguments, so it is not vanilla compatible :)

I never knew this thing existed btw until you mentioned it for [cyclone/prepend]

I have to say it is AWESOME...

If you're using that, you might as well use this to get the initial dsp status:

[loadbang]
|
[dsp-status(
|
[pdinfo]

Alexandre wrote:

I see in pd-l2ork / purr data 3 [output~] objects; two are the same and come from vanilla: one in "3.audio examples" and another in "4.data structures". These both have no help file, but there is the A05.output.subpatch.pd file in 3.audio examples. This should probably just stay as it is...

Agreed. These are just helper abstractions for the help patches there and match up with what's in vanilla and in Miller's book, so we should keep them the way they are.

So, I suggest getting rid of the bad help file and replace it with the good one, which seems to be sitting somewhere else and not getting called upon.

We should just remove the "bad" help patch from extra, then the "good" (pddp'ified) one from 5.reference will be found all right, no need to copy it over to the extra folder. The good help patch comes from purr-data/doc/pddp, the bad one from purr-data/pd/extra in the sources, so we should just remove the latter from the repo and everything should be fine.

also realized that the [output~] found in pd-extended's extra folder is in fsact a copy of [ezoutput~] from pddp (also present in purr-data).

It differs from all the others in contents (as shown by diff), but seems to be functionally equivalent. The only patch I could find where this is actually being used is 4.data.structures/pd-l2ork/ds-demos/violin.pd. I think that in order to clean things up, we should just remove purr-data/externals/pddp/ezoutput~*.pd from the repo and edit purr-data/pd/doc/4.data.structures/pd-l2ork/ds-demos/violin.pd so that it uses the "standard" output~ abstraction.

Just for the record, there is yet another abstraction of this kind, ezdac~.pd, which is being used in the fluid~ and rradical help patches, but this looks and works a bit differently, so I think that we should keep it.

Another suggestion would be to include a new output~ abstraction I worked on and that I'm using for cyclone.

This looks really nice, and I like the extra options that it offers. I also agree that the default quartic mode works much better than logarithmic, which I find almost useless, at least the way it is implemented in the default output~ abstraction. I usually prefer linear, and your abstraction offers all of these, providing configuration via both creation arguments and the control inlet. And those who really insist on the logarithmic scaling can just get it by adding an argument. Very well done!

One nitpick would be that the gop area is really a bit small now if you want to specify all three creation arguments, but we can't really help that if we want to keep the thingy to the size of the old output~ abstraction. And the 3rd argument will probably be used very rarely in practice, so this isn't really a big issue.

There are two minor goofs in the accompanying help patch:

It lists the mode and multiplier arguments in the wrong order (arguments section).
I get this error message whenever I open the help patch: error: value: no method for 'bang'. Not sure where this comes from (Pd can't locate the error), maybe some loadbang which goes awry in there?

Jonathan, once these are fixed, I think that we should really replace the old output~ from extra with Alexandre's. What do you think?

I get this error message whenever I open the help patch: error: value: no method for 'bang'.

This seems to be somewhere in the Gui_control subpatch of output~.pd, but I still haven't found what exactly goes wrong there. @porres hopefully you can make sense of it.

I've also attached an edited copy of the help patch which corrects the argument order and has a couple of typos fixed. output_-help.pd

Well, GitLab messed up the file name, that should be output~-help.pd, of course.

the error: value: no method for 'bang' comes from the ezoutput~ abstraction, not mine :)

something to do with the way it is using the [value] object, i don't know...

I screwed up and changed the order in the patch, not in the help file. I thought of this order in terms of priorities, what do you think?

thanks for the feedback, remarks and corrections

I think that in order to clean things up, we should just remove purr-data/externals/pddp/ezoutput~*.pd from the repo and edit purr-data/pd/doc/4.data.structures/pd-l2ork/ds-demos/violin.pd so that it uses the "standard" output~ abstraction. Just for the record, there is yet another abstraction of this kind, ezdac~.pd, which is being used in the fluid~ and rradical help patches, but this looks and works a bit differently, so I think that we should keep it.

ezdac~ is still the same idea but with less functions. What I hate about it is that it has the same name of a max/msp object, but not the same functionality, and not the same looks (obviously). We may eventually, but not likely, clone this one in cyclone, not in the plans right now anyway... but it bothers me that this could pass as a cyclone object.

I have a voice in the back of my head saying it is bad to remove objects from other libraries, but my heart would love to see both of these disappear from the ecosystem, they're garbage...

It differs from all the others in contents (as shown by diff)

but what about functionality? How can I check "diff"?

cheers

I see the differece, output~ actually fixes an issue that makes ezoutput~ behave very badly

actually, the error comes up IF you have both [ezoutput~] and [pddp/dsp] on the same patch, so, anyway, maybe I'll just get rid of referring to both of them in the related objects, we don't really like them anyway and even feel like getting rid of those ;)

Jonathan, once these are fixed, I think that we should really replace the old output~ from extra with Alexandre's. What do you think?

Sounds good to me.

well, fixed those things, took those pddp related objects out, used the [pdinfo] object, and here it is ;)

output.zip

thanks!

I screwed up and changed the order in the patch, not in the help file. I thought of this order in terms of priorities, what do you think?

I really think that the linear scaling factor should come last, since presumably it will be used only rarely, whereas the scaling mode argument is quite important for people who want to use linear or logarithmic mode.

Thanks for posting the new version, I'll check it over the weekend.

Works great, except that I now have to type [output~ 1 1 2] just to get linear scaling. I really think that the linear scaling factor should be the 3rd creation argument, since it's only relevant for linear mode (and even then will it rarely be necessary to change the value from the default 1 value). Having to specify it all the time just to change the scaling mode is very awkward.

Also, is this identical to the out~ object that you just added in https://github.com/porres/pd-cyclone?

is this identical to the out~ object that you just added in https://github.com/porres/pd-cyclone?

wow, funny you should mention [out~], well, guess I have to talk about it now...

My story with output~ is that i always hated it, then i started working on cyclone which had yet another version and distributed it. So i thought i'd change for something i liked and it was the version I first proposed here. I thought it'd be weird if I distributed my version of output~ in cyclone and then purr data (which is to accept the new cyclone when we're ready) has a different one, so I thought I'd merge them somehow.

Now, I know the dimensions weren't the same, and jonathan asked if I could have one more like it. You've seen one issue about that, which is that you can't really put all three arguments into it and see them... but the only way to fix this is changing the dimensions and format to my original...

Now, I worked on some of the issues I had with output~ and one of them was that I saw no point in having outlets~ unless you could mute "dac~" - so I went ahead and added this functionality. But what I really wanted to do was just get rid of the outlets and the "dac~" argument/functionality. But That would change things a lot... maybe not good...

The thing is that even before I proposed a new output~ here, I had the idea on working on a new abstraction and with a different name: [out~]. It's different cause it doesn't have any outlets and I could make it simpler getting rid of the 'dac~' on/off thing. It's an abstraction for someone who just want to get sound output and that's it. So it has only 2 arguments now and plenty of room to write them and read them.

So, for gain adjustments and sending the signal through outlets, I'm thinking about making another abstraction just for that (with no dac~ output). I believe it's better if objects are simpler and more dedicated than having all sorts of different behaviours and capabilities...

Now, this new [out~] abstraction of mine will be officially put into a new library I'm yet to release, I just gave it an actual name yesterday, it is called "else"... as you know, [out~], [output~] or whatever shouldn't be officially in cyclone...

https://github.com/porres/pd-else/tree/master/out

This is also newer than what was in cyclone, though I've updated cyclone as well now.

So, once I had the "else" library more polished, I would like to propose it into the new purr data. These are objects I felt were missing in the Pd Extended eco system. Cause, well, I have this big computer music tutorial, with over 350 examples, and I exhausted all the existing objects in Pd Extended, so I'm going to this library to include yet something "else" that I could use for my examples.

And once Purr Data is out, I'll start working on porting all these examples from Pd Extended to Purr Data

of course i'll make use of the new cyclone in my new examples and this is also a motivation behind me working on cyclone...

So, about arguments... Like I said, I actually think the whole design situation of output~ is complicated. I don't really like the "dac" argument, but I thought it was important and maybe should come in first.

I'm thinking obviously about priority of changing the parameters, and in general purposes, not my own. And I do think the gain adjusment parameter is important as I use that one a lot. A gain of "1" is usually too loud, and if you have 2 output~ objects, you really wanna scale both of them to 0.5, so when they add together, than you have a maximum of 1! Now, if you do that as the 3rd argument, it'll extrapolate the boundaries - And if you have 3 or 4 output objects, you'll want something like 0.33 or 0.25, this is still fine and possible if the gain is the 2nd argument.

Now, if you're someone who cares more about changing the scale mode and not the gain, you can still set it as an argument without extrapolating the boundaries.

Of course, if you wanna change both or the 3 of them, then you have to use messages into the right inlet one way or the other.

Like I said, none of this is an issue with my new [out~] object, and I gave it up on my version of output~ that would let you see all arguments, cause, well, I don't really like [output~], so this will be for purr data only, I won't distribute it in cyclone or carry anywhere else

Alexandre wrote:

And I do think the gain adjusment parameter is important as I use that one a lot.

Yeah, I mistakenly assumed that the gain factor was only for the linear mode, but it's really a makeup gain for all of the modes, I understand that now. So it certainly makes sense to have the arguments in the order in which they are.

But what I really wanted to do was just get rid of the outlets and the "dac~" argument/functionality.

Yeah, that would simplify things a lot. The vanilla output~ version doesn't have any outlets either. I just went through all the patches included with purr-data that use the extended output~ abstraction, and sure enough there's not a single one that uses any of the outlets either (not even the control outlet). As a matter of fact, I can't think of any reason why you'd want to use the outlets of the extended version of output~ at all.

I think that we should just get rid of all the outlets. That would make output~ functionally equivalent to your out~ abstraction, just with a gop area that makes it suitable as a drop-in replacement for the extended version of the abstraction. @jwilkes any objections to that?

Somewhat off-topic, but while playing around with Alexandre's out~ abstraction from https://github.com/porres/pd-else/ I just noticed that it doesn't work with pd-l2ork/purr-data, since neither pd-l2ork nor purr-data seems to support nested gop areas. @jwilkes do you know why that is? Is it a fundamental limitation of the pd-l2ork/purr-data canvas implementation, or is it that this functionality never got backported from vanilla? Should I open a separate issue for it?

I think that we should just get rid of all the outlets.

OTOH, you went to quite some lengths to implement and properly document the pass-thru feature in your version, and it may well be handy for some use cases, so on second thought I'd say that we may just want to deploy it the way it is now. Jonathan?

There's only one thing I don't like-- the multiplier arg. I'd much rather the top value of the slider always be "1". That way the user can predict the behavior of the abstraction no matter where it occurs in the docs. A smaller but important side benefit is that removing this would guarantee that the remaining two args are always visible.

Otherwise it looks like a great improvement. It is way more readable inside the abstraction, which is a big benefit.

Wrt the original design-- I wonder if the "dsp" toggle is confusing to new users unfamiliar with Pd's toggle style. In a way it looks like "dsp" is "crossed out", potentially implying "no dsp".

since neither pd-l2ork nor purr-data seems to support nested gop areas

Scratch that, nested gops work fine in purr-data, sorry for the false alarm.

It's just that the gui elements in the nested gop are placed slightly different in purr-data, and the whole gop gets ignored if they don't fit into the gop. If I fiddle with the gui elements of the nested gop in Alexandre's out~, it works all right in purr-data.

One other thing-- what do you think of the following change to the slider size and iemgui positions: output_.pd

This adds a bit of padding in the GOP area, and also displays the GOP content properly in "-legacy" mode. This means everything displays properly in Vanilla, too.

I really wish we could somehow do away with this position discrepancies somehow, and it's not something we can really keep up with for every single gop abstraction. But for an abstraction used as often as something like [output~], I thought it would be a good to ensure that its compatible.

It's just that the gui elements in the nested gop are placed slightly different in purr-data, and the whole gop gets ignored if they don't fit into the gop. If I fiddle with the gui elements of the nested gop in Alexandre's out~, it works all right in purr-data.

Ha, just suggested a change above with this in mind.

For a broader discussion about -legacy mode and Vanilla GOP compatibility see #190

This means everything displays properly in Vanilla, too.

Jonathan, that patch will never work in vanilla, it uses pdinfo. :)

For a broader discussion about -legacy mode and Vanilla GOP compatibility see #190

Yes, I've seen that, and I think that having a flag in the gop properties is the way to go, if that can be made to work without breaking patch compatibility with vanilla. That would also nicely solve the problem with stuff disappearing from gop patches in patches created with vanilla because of misaligned gui elements.

That -legacy command line flag isn't really very useful, since it's a global setting. If you mix patches created with pd-l2ork/purr-data and vanilla, that just doesn't work. But having a per-canvas (or even just a per-toplevel) flag is a great idea.

There's only one thing I don't like-- the multiplier arg. I'd much rather the top value of the slider always be "1". That way the user can predict the behavior of the abstraction no matter where it occurs in the docs.

I have to say that I'm with Alexandre here. There are some cases where a constant multiplier is just convenient (and user-friendly!), to make up for extra quiet or extra loud input signals, and/or multiple outputs. So it's great to have that option, provided that it is used with diligence (and presumably that would be the case in the accompanying docs, where we are in control and can ensure that). If a noob then decides to crank the multiplier in a help patch up all the way until his speakers explode, then it's his fault, not ours. :)

If a noob then decides to crank the multiplier in a help patch up all the way until his speakers explode, then it's his fault, not ours. :)

Pd 101: learn to turn the master volume all the way down and then slowly raise the level when trying a new patch. That's the first thing that I teach the students in each and every Pd course. And they forget it all the time anyway. Most common case: Make a volume slider and forget to change the default 0..127 range. ;-)

Wrt the original design-- I wonder if the "dsp" toggle is confusing to new users unfamiliar with Pd's toggle style. In a way it looks like "dsp" is "crossed out", potentially implying "no dsp".

That's exactly what I first thought, too. Maybe there's a way to make the cross effectively "invisible" (or at least less prominent) by adjusting the selected state color scheme in the set_color subpatch?

I have to say that I'm with Alexandre here. There are some cases where a constant multiplier is just convenient (and user-friendly!), to make up for extra quiet or extra loud input signals, and/or multiple outputs.

It's convenient for writing patches but not for reading them. I'd much rather read [*~ 123]---[output~] than [output~ 1 123], esp. given that the "2" and the "3" hides behind the dsp button.

It's convenient for writing patches but not for reading them. I'd much rather read [*~ 123]---[output~] than [output~ 1 123], esp. given that the "2" and the "3" hides behind the dsp button.

You do have a point there. Yeah, I'd probably prefer to do it that way as well. And we also still have the gain message which can be passed to the control inlet.

One other thing-- what do you think of the following change to the slider size and iemgui positions

Looks ok to me, except that the volume label on the slider is too far on the right now. I'd move it a bit to the left so that it's approximately in the center of the slider.

Jonathan, that patch will never work in vanilla, it uses pdinfo. :)

i added that now, i was using a vanilla hack before, what I'm really using from purr data is the $@ argument parsing, so I know if no arguments are being sent so i can call default arguments (i always wanted to do something like that, so cool).

I wonder if the "dsp" toggle is confusing to new users

It's convenient for writing patches but not for reading them. I'd much rather read [*~ 123]---[output~] than [output~ 1 123],

both these issues were dealt with in the first suggestion i sent here, which had a different and new design, but in order to keep the same dimensions I had to sacrifice that.

Well, this has been generating lots of discussion, which is great! If that many thought were given before, we wouldn't have to think now about how to deal with this heritage. But as I see it, we're at a point where we need to compromise something - we can't have the cake and eat it too...

I'd be fine with anything if it just gets rid of the terrible log scaling, that's my big issue. The quartic scaling is what miller suggests (despite his output abstraction) and what i've mostly seen in the pd world, seems like a good default for me.

Now it all depends on how you wanna keep this abstraction. A more conservative position would be to keep the same design, dimensions and the same inlets/outlets. So if that's important and you hate the clumsiness of hiding arguments, one of the arguments should go away, and maybe "gain" because that's the one which can take floats and take more space.

A less conservative measure just opens too many options... new design, getting rid of outlets, etc... I'm sure the outlets weren't being used in the documentation, cause they're kinda pointless, but who knows, maybe someone else uses it in their patch... the inlet for the slider value might not be used in the documentation, but I'm sure anyone who used this abstraction with a midi controller uses it.

I guess you can adapt purr data's documentation with any crazy change in this object, like getting rid of outlets and a different dimension. The issue is how you feel about messing with this as opposed to keeping it a perfectly backwards compatible object for Pd Extended. I, for one, am the least conservative guy. If it were up to me, I'd reboot it completely, I'd get rid of output~ as it is completely, cause I just hate the idea of inheriting and keeping garbage instead of improving things... Pd Extended wasn't all that great and sacred, it had a lot of garbage and now it is dead... but I understand and respect the effort of trying not to break too many things.

Well, about all this, what I did was that I worked on something new and changed the name, you know it, it's [out~]! So I'm good with that and i don't care about [output~]. You can keep this improved and backwards compatible version without the gain argument which seems to be reasonable, without sacrificing anything, and we close this issue.

Now, another thing would be if you liked my new [out~] object. I wanna distribute in my library, and maybe that library could be included in purr data. But I don't know, it still feels like adding yet another abstraction, let us remember we have: [output~], [ezoutput~] and [ezdac~]... If you care at all about not keeping garbage and related objects, maybe you don't want to add yet another one.

I'm not sure yet how you people feel about deleting and getting rid of objects like that. I know it's been mentioned about deleting ezoutput~ for instance. As I said, I'm personally totally fine of just throwing away lots of stuff that seem bad, but I understand a decision to keep them and deal with that hassle.

But if you like my new [out~] abstraction and wanna keep the old stuff, there's always the possibility of deprecating the old objects. So if that's the case, I could suggest adopting [out~] it in purr data's documentation as well as providing the improved [output~], but keeping it as a deprecated solution for backwards compatible patches. You can always put it in the documentation that there's a more convenient and new object design you consider is better.

[out~] wouldn't need to be distributed in my "else" library, it could be in the "extra" folder of purr data, along with the deprecated [output~]

what do you say?

I added more information about scaling modes and the gain parameter in [out~], https://github.com/porres/pd-else/tree/master/out

I could do that too for [output~]

I didnt get it, how can i make out~ compatible to vanilla and purr data?

I'd be fine with anything if it just gets rid of the terrible log scaling, that's my big issue. The quartic scaling is what miller suggests (despite his output abstraction) and what i've mostly seen in the pd world, seems like a good default for me.

I fully agree with that. It's worth switching to the new one for that alone, but also for the nifty new features and, as Jonathan mentioned, because of the more readable implementation.

Pd Extended wasn't all that great and sacred, it had a lot of garbage and now it is dead... but I understand and respect the effort of trying not to break too many things.

At least we shouldn't break too much stuff all at once. :) You're right, there's a lot of broken stuff in the lesser-used parts of the included external and abstraction library and the accompanying help and demo patches. Ico and Jonathan have done a great job to make at least the more important stuff work or getting rid of some horribly outdated parts, but it's a large library and this is a greater task than any single individual can do. I think that we'll have to rely on the community to get that ironed out over time. Rome wasn't built in a day either.

I know it's been mentioned about deleting ezoutput~ for instance.

It was me who suggested that, but on second thought this isn't a really big issue if at all, we can just keep it, it won't hurt anyone. :)

Now, another things would be if you liked my new [out~] object.

Personally, I think that it would be a nice alternative and should be added, so feel free to send Jonathan a merge request for that. :)

But first things first, let's focus on getting output~ fixed, shall we? That's the reported issue here after all. Which brings me to...

Now it all depends on how you wanna keep this abstraction.

I took Jonathan's version now, which has some minor fixes in the layout of the gop area to make it compatible with -legacy mode, corrected it (there was a missing $@ in the load_args subpatch, wonder how that happened), and made the following additional changes that we discussed recently:

removed the second gain creation argument (but the gain message still works as before); also updated the help patch accordingly
modified the selected color scheme of the dsp toggle in the set_color subpatch to make the cross effectively invisible, to fix the "crossed out" effect that we complained about

Here it is in its full glory, so that you can take it for a test drive. (Be warned that I didn't have the time to test it myself yet, will do that later tonight.)

output4-ag.zip

I'd say that this is ready to go in now once I've done some final testing. Jonathan, would you prefer a merge request?

I didnt get it, how can i make out~ compatible to vanilla and purr data?

Not sure what you're referring to, but there's a minor issue in out~ with the nested gop area which causes the volume slider not to be rendered unless purr-data is run in -legacy mode. Fiddling with the dimensions and/or positioning of the slider will fix that.

Jonathan, would you prefer a merge request?

Yes, that'd be great.

Fixed a leftover $3 in load_args, hopefully I got it right this time. At least it works for me now.

output5-ag.zip

Will submit a corresponding merge request tomorrow, if there aren't any further complaints.

fixed a mistake in the documentation (mute message)
added details to scaling mode and gain
fixed a bug introduced by removing the gain argument where the scaling mode was still assigned to the 3rd argument

output5.zip

my problem with the dsp toggle now is that it is not clear that it is a toggle button, I have an idea to work on it in the documentation, but also change the lable to "on" or "off", this could actually be nicer since I'm using "on" / "off" messages to set the dsp on or off, let me upload this idea next

oh, i see you fixed that bug too now :)

The new "scaling modes & gain" help page is very nice. I noticed the following typos, though:

and input slider -> an input slider
muktiple -> multiple

Ok, Alexandre, I'm going to wait for your final fixes and then do the merge request tomorrow. Or you can just submit the merge request yourself (works pretty much like a pull request on github).

fixed typos, added the on/off label and more documentation about the DSP statusoutput-on-off.zip

Thanks, looking good. Just one more thing: On my Linux system at least, pdinfo dsp-status always gives 0 when the patch is first loaded, even if purr-data is already running and dsp is turned on when the patch gets loaded. Not sure why that happens, but I was able to fix that by inserting a 10 ms delay after the loadbang in the DSP_state subpatch. The resulting version is attached below:

output-on-off-ag.zip

Jonathan, I'll send you a merge request in a minute.

mentioned in merge request !42 (closed)

looks like we need a new issue for pdinfo :)

Thanks, looking good. Just one more thing: On my Linux system at least, pdinfo dsp-status always gives 0 when the patch is first loaded

That's a race. I should be using the global dsp status getter from m_pd.h instead.

Let me know when/if you fix it, then I can prepare a new merge request for Alexandre's final version instead.

All set: 210c4465

Nice, thanks. Will send you a new merge request later.

All set: 210c4465

Nope, just tested it, still the same. Try for yourself with the attached test patch: launch Purr-Data, switch on dsp, then open the patch => dsp-status still reports 0 (at least on my Arch system).

pdinfo-bug.pd

Nope, just tested it, still the same. Try for yourself with the attached test patch: launch Purr-Data, switch on dsp, then open the patch => dsp-status still reports 0 (at least on my Arch system).

That's accurate. The loadbang fires before glob_evalfile resumes dsp.

The question is how we want to expose this to the user. Possibilities: a) leave it, b) report dsp-status as 1 in the middle of eval'ing the file, c) report a different state like "-1" to signal this special case.

That's accurate. The loadbang fires before glob_evalfile resumes dsp.

Then it makes sense to just leave it the way it is. The version of Alexandre's patch I submitted as !42 (closed) properly deals with this by delaying the call to pdinfo, so everything works as intended with that version.

I'll document this in the help file for [pdinfo]

Hm, I think this needs an issue... #197 (closed)

mentioned in issue #197 (closed)

I believe all these issues have been solved for the upcoming rc.

closed

bad help file for [output~] in extra / new abstraction suggestion

Designs

Child items 0

Activity