hallo IOhannes and thanks for your reply :)<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
within Pd you are free to do whatever you want with your signal:<br>
e.g. you can run your internal signals in a range [-1e5,+1e5], and it<br>
will all be just the same (as long as you take care to scale the signals<br>
back into the standardized range before your [dac~]).<br>
there is no "clipping" in Pd [1].<br></blockquote></div><br>i understand that 32bit floating point handling pd makes it possible to use audio signals in many other ways than just send them to dac to produce sound (like table lookup for example).<br>
the other benefit is that the manipulation of signals is much more accurate and this applies also after the conversion to fixed point signals. There is software that uses 64bit float internally for that reason.<br>let's assume now that we need a vu just before the dac, e.g. to monitor the signal before it becomes analog.<br>
in this (rare?) case, why lose the upper 1/3rd of the GUI object?<br><br>can you please answer the last question of my first mail?<br>"Would it be meaningful to offset the incoming values to make use of the
visual space above 0dB or would it mess up the scaling?"<br> e.g.<br><br>[osc~ 100]<br>|<br>[env~ ]<br>|<br>[-94] (instead of [- 100]<br><br>would give about +3dB rms and the peak would be at +6dB. so you just consider "+6dB" as the real 0dB.<br>
<br><br>thank you<br clear="all"><br>-- <br>ypatios<br>