Hi all,

I needed to have some more long-running visualisation of waveforms in PD, so as there is no vanilla [scope~] object, I thought I'd use [tabwrite~] with [array], as commonly recommended - however, I have stumbled upon a somewhat strange behavior, which I'm not sure whether it's a bug. This is on Ubuntu 18.04, vanilla Puredata from Ubuntu repos (0.48.1-3)

So, basically I made a patch, which is mostly reused help of [tabwrite~] :

The patch itself is here: test-array-scopevis-metro.pd

So, basically, I want to view signals as if on a scope with timebase of 1 second. My PD/Media/Audio Settings tells me: Sample rate: 44100, Block size: 64, Delay (msec): 25

So, all I have in addition to what was there in the [tabwrite~] help, is a few objects to set the array98 array size to 44100 when the patch is loaded - so there is enough memory to record 1 second of signal. And then I've added a metro, so it bangs the tabwrite~ each second (each 1000 msec) - the idea being that I bang the tabwrite~, it records 44100 samples in a second and shows them, then after that second I bang again, it records 44100 samples in a second and shows them anew and so on - pretty much like an oscilloscope at a timebase of 1 sec would do.

However, the actual response is shown in this video:

test-array-scopevis-metro.ogv

That is, when I start the metro at 1000 msec, it keeps banging for at least 10 times, without the array ever refreshing the waveform display?! Then, when I stop the metro, the waveform is displayed ?! At that point, I draw whatever in the array graph so as to "reset" this display, change the metro to 1001 msec - and start the metro again. This time the display does update as expected - but only after an initial delay of some 2 seconds (or three bangs) - I would have otherwise expected a delay of 1 second (two bangs).

Does anyone knows why this happens, and how to get a more reliable behavior for this kind of case? My guess is, for a [metro 1000], PD actually does not have enough time to fill the entire array with all 44100 samples, and thus it never updates the graph - apparently 1 millisecond extra is enough for PD to realize that the array has been filled, and so it updates the graph, but then why does it take 2 sec (at 3rd bang) to update, and not only 1 second (at 2nd bang)?

@pomolo This needed re-writing.
Dynamic range is meaningless in Pd (or any computer digital processing), in that it cannot be reproduced in the real world. The dynamic range is determined by the ratio of the biggest possible number to the smallest. Even in Pd 32-bit the biggest possible number is massive compared to the smallest.
Of course for FFT the dynamic range is constrained, as it depends on the sample-rate and bit depth.......
https://en.wikipedia.org/wiki/Audio_bit_depth

dB(something) becomes fixed, with real measurable (but weighted) values, when it is measured as sound waves in the air....... and it is fixed then because it is universally agreed that 0dB is the smallest pressure wave that can be heard by a human.
Only then can you define +100dB

RMS..... volts do not "exist" either until the [dac~] does it's work
How you scale the numbers to match your soundcard is up to you.
As Pierre says above 1V = +100dB has been "chosen" as sensible for Pd.
But as we all know, a traditional VU meter will show 0dB as "maximum".... not +100dB.
Hence the dB-100 part of the formula above.

+1...-1 (about zero) is considered safe for [dac~]
If the soundcard sees 1 as max for its conversion to analog all is well.

At 1.00001 it will clip. This value is fixed and known. There is nothing to be done about it.
The dynamic range of your card is not from 0dB to +94dB.
(Well....... it is, but that is what confuses the mind).
Its dynamic range is determined by its noise floor, and your card has a noise floor 94dB "below" the maximum that it can output before clipping.
The dynamic range of your card is from -94dB to 0dB........ if we agree that it will "clip" above 0dB.

So if Pd +100dB is 1 (in fact shown on the VU Gui in Pd as 0dB) then when the Pd Gui shows -95dB any Pd output will be masked by the noise floor of the soundcard....... (or more likely by dither if the soundcard is any good), as the very small numbers cannot be properly resolved, and that results in unpleasant audible artefacts.

And then there is the metering of the soundcard (if it has any).
Because it was traditional to overload magnetic tape, many of the first pro digital systems actually showed 0dB (the max number without clipping) as +18dB..... and showed red bars from +12dB upwards. Trying to make sure you would not clip your recording.
This has most of the info you are looking for I think........
https://sound.stackexchange.com/questions/25529/what-is-0-db-in-digital-audio

As with any analog or digital system you need to know "where you are" with the audio chain before you start work. Set an oscillator into a [dac~] with a VU driven by [pvu~]. You will see 0dB on the meter (1V RMS in Pd).
What does your soundcard show?
Do you need to trim the output of all your patches with a [*~ ?].?
Probably not.
Are there standards
No, not for metering.
If it shows +18dB or +12dB that is probably correct.
0dB on the Pd VU should show as the last bar on your soundcard before the red bars, but the soundcard metering might be lying..... to save you from yourself.
You will only get clipping where the maximum possible value is exceeded.

Volts, RMS or peak, are measures on a linear scale.
But our ears hear "power" and so the dB scale of relative power is a logarithmic scale.

The formula above equates the linear scale to the log scale, but they can "slide" against each other.
Putting an amplifier increases the volts, but how much more volume (dB) you get depends on the efficiency of the speaker...... losses in cables etc.

Only when you have decided 0dB can you say what is 100dB.
Or when you have decided 100dB you can say "how much" is 0dB.
Because it is all relative.
David.

hi folks, thanks for the kind comments!

sure ill share the patch eventually but right now its an uncommented messy laboratory affair. best thing you can do right now is look at the patch image above which is quite self explanatory.

here is the vs rom in one wav file, scan this in 128 chunks of 128 samples and you have the single wave data.

vsallwaves.wav

harmonic aliasing is best described by acreil in the above mentioned blog post because thats where i got the idea from. the rest is trial and error and a lot of listening to integer combinations.

harmonic aliasing is actually my own term for what im trying to do. here is how i would describe it:

• if you repeat 128 samples with a phasor at 128 hz (or 64/32/16/8/4/2) or any multiple of 128 your phasor restarts exactly at the beginning of the wave data and the aliasing frequencies generated by the steppyness of the data will follow the harmonic overtone series 1,2,3 etc. depending on the multiple.

• if you introduce another prime divider ie. 3 as in 128 / 3 the phasor will line up with the sample data every 3rd sample and the osc will alias at the 3rd subharmonic frequency which will be somewhat more disharmonic than any overtone.

• another way to look at it would be the pattern repetitions. at subdivision 5 the phasor starts at 5 different points in the sample data and its easy to imagine that the readout patterns are all slightly different ... but the whole thing cycles after 5 phasor rounds = 5th subharmonic..

• if you subdivide 128 further with a higher prime ie. 563 you will get 562 different sounding samples until nr. 563 lines up again. get the idea?

this is all very easy to hear once you experiment with prime subdivisions and multiplications. just remember its all based on synching the data flow from the sample with the frequency of the index phasor. this will work with ANY sample data, the vs rom is just cool to use for vintage synth fans.

whats important for proper aliasing is that you use a simple [tabread] into the data without any interpolation like tabread4 or oversampling!

all the other elements in the synth like delay, waveshaper, sequencer follow the same rule as they are just repetition devices like the wavetable oscillator.

if you finally synch everything to the sample rate of your soundcard the voltages that hit your speakers will repeat in exact patterns. thats the idea of this synth: precision number repetition controlled by harmonic/disharmonic integer combinations ... just like the great 80s synths waldorf microwave or prophet vs.

wavey_lays: a delay effect which changes the delay-time ([line]) based on adding [osc~] + [phasor~]

wavey_lays~.zip

I have found one of my favorite sound effects to be what happens when you change a delay line while you are playing.

So this effect does that automatically while you play according to the following logic:

[osc~] And [phasor~] to [+~]

changing the DIY2 (mono-delayfb) delay time according to that logic.

Change the osc or phasor and it changes the shape of the [line] object that changes the delay time.

Hope you enjoy it.

Sincerely,
Scott

p.s. the [rand_note_signal~] is only there for testing so you can hear what it sounds like and the 808_state.pd is required by the original DIY2 mono-delayfb abs.

MESSAGES to right inlet:;
(in this order, i.e. [0 $1(;
[1 $1( etc. off|on: 0|1;
osc:0-1000;
phasor:0-1000;
metro:0-1000;
feedback:0-1;
gain:0-1;

3 things:

1. The signal outlet from the [*~ ] object should go into the [snapshot~] , not the [metro]. [metro] is a control level object and can't take signal input. [snapshot~] takes a signal for its source and a control level "bang" message to trigger it, both in the same input.

2. There's no need to use [bang~] and metro at the same time. [bang~] is essentially a metro already, firing once every DSP cycle, which is faster than [metro] can manage. So either use [bang~] to send a "bang" message at the highest possible rate, or use [metro] to send a "bang" message at any other rate.

3. A low-pass filter plus a high-pass filter is equivalent to a band-pass filter. There are several band-pass filters in PD to choose from, including [bp~] and [vcf~]. [vcf~] has a signal input for the centre frequency, so if you use this, you won't need to worry about converting signal to control at all.

@CBronisimo The easiest way to do such a thing is to use a metro as a clock signal at the fastest time division you'd like to obtain. Then use a counter, a [mod N] and a [sel 0] to bang every N beats.
This way you can have lots of pseudo-metro functions that depend on just one metro, and they will be in sync every time. Obviously you'll have to reset the counter if you stop and restart the clock metro.
For example, if you want a whole time to beat every 1000 ms, set metro to 1000/32, then use [mod 32] to bang whole time, [mod 16] to bang 1/2, [mod 8] to bang 1/4 and so on up to 1/32 with no mod at all, or [mod 64] to bang twice the time etc... If you plan to go even faster just set the clock metro to 1000/64 or 1000/128 and change [mod N] accordingly. You can even get dotted and odd time signatures this way.

Hope this helps!

@phil123456 It's hard to tell with the picture.... but it looks as though sending the number to all of the [pd phaser-bank] objects and letting them decide how to "use" that number would be easiest.
If you make an abstraction of [pd phaser-bank] as maybe [phaser-bank] and then place that many times in the patch with a number argument........
[phaser-bank 1]
[phaser-bank 2]
[phaser-bank 3]
etc.
Then in [phaser-bank] you could use
[r number_being_sent]
|
[t b f]
| |
[$1<]
|
[do it $1 times]
to let the abstraction decide it's action...........

Does that make sense? it was posted in a hurry....
David.

Hi, this is the driver that i connect to arduino : http://ruggedcircuits.com/html/rugged_motor_driver.html

in arduino I've a patch that read the PWM of two pin and i need to write a sequence like this with the digitals output :

void StepperHighSpeed::stepMotor(int thisStep)
{
if (this->pin_count == 2) {
switch (thisStep) {
case 0: /* 01 */
digitalWrite(motor_pin_1, LOW);
digitalWrite(motor_pin_2, HIGH);
break;
case 1: /* 11 */
digitalWrite(motor_pin_1, HIGH);
digitalWrite(motor_pin_2, HIGH);
break;
case 2: /* 10 */
digitalWrite(motor_pin_1, HIGH);
digitalWrite(motor_pin_2, LOW);
break;
case 3: /* 00 */
digitalWrite(motor_pin_1, LOW);
digitalWrite(motor_pin_2, LOW);
break;
}

did someone can help me ?

Thanks

Best

Enrico

Sorry I'm getting errors, can you help me?
I've installed the montreal mtl library, but still I have too many objects missing

mtl/qompander~ /id compander
... couldn't create
mtl/clkMaster 120
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
[msgfile] part of zexy-2.2.3 (compiled: Sep 22 2010)
Copyright (l) 1999-2008 IOhannes m zmölnig, forum::für::umläute & IEM
mtl/player~
... couldn't create
mtl/clkSlave 4 16
... couldn't create
mtl/kick808~
... couldn't create
mtl/clkSlave 1 4
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create
setting pattern to default: /home/leopard/Documenti/Music/_sperimentazioni/_PURE DATA/Bangboum/./moteur/*
mtl/player~
... couldn't create

Hey
I'm using phasor for an index to a tabread~ to play a sample.
I'm also using line~ as an envelope to control audio output.

The timing for the envelope is set by the size of the sample size and samplerate~ as well as the frequency for the phasor~.

The magnitude of the phasor is adjusted to the sample size.

The sample player can be re-triggered and when this happens a line~ is set to go to 0 in 5ms,
a delay is set for 5ms,
then bangs another line~ to go to velocity in 0,
as well as setting phasor~ frequency to 1/t and phase to zero.

At which time another delay is setup at samplelength in ms.

After the sample is played the phasor~ frequency is set to 0 then
another line~ to 0 in 5ms is sent to the [*~] .

This causes a glitch when the sample is retriggered because the phasor~ is reset to zero and starts replaying the sample.

This glitch can not be heard when the sample is not re-triggered so maybe it's a control vs signal timing issue.

I did hear the glitch at the end of the sample re-triggered or not using vline~.

So my question is how do you do audio rate envelope triggering of envelopes ? I would post the patch but it is a mess. A good answer or pointer to some reference material would be greatly appreciated. I haven't quite wrapped my head around the sample and hold sampler examples yet.