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
Documentation issues #1037
Conversation
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
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. |
(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.) |
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 |
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 |
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. |
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 :) |
help file of slop~ was also still trying to load out1~ but giving an error instead. this new PR fixes it #1051 |
Improvements, fixes and updates to the documentation to document existing features