Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation issues #1037

Merged
merged 10 commits into from Jun 3, 2020
Merged

Documentation issues #1037

merged 10 commits into from Jun 3, 2020

Conversation

porres
Copy link
Contributor

@porres porres commented May 26, 2020

Improvements, fixes and updates to the documentation to document existing features

porres added 10 commits May 26, 2020 19:49
closes pure-data#549 (mainly change the description of %p)

I also added more details and examples for all types and also the syntax field.

And I also added examples on how to use backlash to include a symbol with spaces, which now will be possible in the 0.51-0 version (so I put "updated to 0.51)
documents equal message, replaces pure-data#811
imporoved information on what the secondary inlets set, see discussion in https://lists.puredata.info/pipermail/pd-list/2020-03/127077.html
better explanation on how to deal with '$0'
This is a major overhaul in the documentation of iemguis. The main motivation was to add the new undocumented way to set colors with hex notation, so this PR closes pure-data#1019 - there are still examples that show how to set the old way of setting colors.

I got carried away and just added detailed information on all parameters and added new examples. More notably, I added an example on how to use [vu] with env~ and slop~ (which closes pure-data#977 )

In this process I also encountered other documentation issues and fixed them all. Hence this PR also

- closes pure-data#1020
- closes pure-data#993
- closes pure-data#1003
- closes pure-data#1000

I also simplified the x_all_guis.pd file and removed the need for it to be called with arguments that were loaded inside it. It wasn't very clear what it was trying to illustrate with it, but now all the possible information is clearly described in the documentation anyway.
closes pure-data#995

I have not only added information about the symbol box, bul also more detailed information in general, and added "see also" for [[tgl] and [nbx]
partially fixes pure-data#1023

This has a better example on how to use the [vu] object, and is the same example as I implemented for the help file of [vu].

I've made other changes to the help file of slop~, but they are all aesthetical, like realigning the [pd parameters] subpatch in  the [pd compander-limiter] section, so it's more readable
This makes the alasysis to the vu inside out1~ the same as the one I made to the help file of slop~ and also the help file of vu, making it consistent. I also changed the level facvtor as discussed in 3d52501#commitcomment-39311591

this fully closes pure-data#1023
@millerpuckette
Copy link
Contributor

Shouldn't the VU meter go all the way to the top when the signal clips? That's why I use -88 and not -100 - I think of the top 12dB as headroom before the signal gets trashed. (Otherwise, why show that range of values at all?) But I might not be understanding how standard VU metering is done.

Except for my doubts about the VU metering I think this is all on target.

@millerpuckette
Copy link
Contributor

(also, I intended for '50' on the gain control to map to unit gain, so that we can have some headroom. This should somehow be made clearer in teh visual design of the out1~ object I guess.)

@porres
Copy link
Contributor Author

porres commented Jun 3, 2020

Shouldn't the VU meter go all the way to the top when the signal clips?

Nope, [vu] comes with a scale in dBFS, where 0 dB is the maximum (clipping) value, and what corresponds to 100 dB coming out of env~. So anything above gets red and tells you your signal is "dangerous" - that is, it'll clip.

Depending on what your doing in your patch, you can generate signals at levels higher than desired, so this is why [vu] has this danger/red zone above 0 dbFS.

For example, when you have a [noise~] object into it, you can see a peak level detection at about 0 dB, but if you maybe unintentionally have 2 white noise sources coming in, then it goes higher than 0 dB

Screen Shot 2020-06-03 at 01 56 50

@millerpuckette
Copy link
Contributor

This is a choice imposed by the vu~ object, not by the meter, which, itself, merely displays numbers from -100 to +12 with anything above 0 showing some red. These numbers are intended as dB but aren't attached to any particular scaling (such as 0dB <--> 1 (peak amplitude), or 12dB <-->1, or
whatever. My experience with VU meters in real situations is that, in analog days, red implies the possiblity of soft distortion but the hard clip point is at the top or even above the top of the scale. I don't know what common practice is for digital ones, but I'm pretty sure that in at least some DAWs, red doesn't mean "the signal got clipped" but that "you're in danger of clipping".

@Spacechild1
Copy link
Contributor

Hi Miller, I think Alex is right about VUs in the digital domain. In a DAW, the VU meter would typically show anything above 0dBFS as red, indicating that the output would be clipped.

@millerpuckette millerpuckette merged commit 4a90532 into pure-data:master Jun 3, 2020
@porres
Copy link
Contributor Author

porres commented Jun 3, 2020

Yeah, don't worry, I'm totally sure they are intended as dBFS, and the headroom is just so you know you're doing something wrong.

Cool, I just have to do another update, as I was using [out1~] in the help file of [vu] as well :)

@porres
Copy link
Contributor Author

porres commented Jun 3, 2020

I was using [out1~] in the help file of [vu] as well :)

help file of slop~ was also still trying to load out1~ but giving an error instead.

this new PR fixes it #1051

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants