vstplugin~ 0.2.0
[vstplugin~] v0.2.0
WARNING: on macOS, the VST GUI must run on the audio thread - use with care!
searching in '/Users/boonier/Library/Audio/Plug-Ins/VST' ...
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/BreakBeatCutter.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Camomile.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Euklid.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/FmClang.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Micropolyphony.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/PhaserLFO.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/pvsBuffer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smGrain3.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smHostInfo.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smMetroTests.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smModulatingDelays.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smTemposcalFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/smTrigSeq.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SoundwarpFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SpectralDelay.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/SyncgrainFilePlayer.vst'... failed!
probing '/Users/boonier/Library/Audio/Plug-Ins/VST/Vocoder.vst'... failed!
found 0 plugins
searching in '/Library/Audio/Plug-Ins/VST' ...
probing '/Library/Audio/Plug-Ins/VST/++bubbler.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++delay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++flipper.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/++pitchdelay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ABL2x.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/BassStation.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/BassStationStereo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Camomile.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Crystal.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Ctrlr.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Dexed.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Driftmaker.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/GTune.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Independence FX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Independence.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/JACK-insert.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Lua Protoplug Fx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Lua Protoplug Gen.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Ambience.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Bandisto.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda BeatBox.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Combo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda De-ess.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Degrade.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Delay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Detune.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Dither.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda DubDelay.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda DX10.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Dynamics.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda ePiano.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Image.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Leslie.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Limiter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Looplex.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Loudness.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda MultiBand.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Overdrive.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Piano.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RePsycho!.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RezFilter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RingMod.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda RoundPan.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Shepard.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Splitter.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Stereo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda SubBass.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda TestTone.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda ThruZero.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Tracker.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Transient.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda VocInput.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mda Vocoder.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mdaJX10.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/mdaTalkBox.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ME80v2_3_Demo.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Metaplugin.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/MetapluginSynth.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Molot.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nektarine.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nektarine_32OUT.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Nithonat.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Obxd.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Ozone 8 Elements.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_16.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_32.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVST_64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_16.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_32.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/PlogueBiduleVSTi_64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/sforzando.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Sonic Charge/Cyclone FX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Sonic Charge/Cyclone.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/Devil-Loc.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/LittlePlate.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/LittleRadiator.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Soundtoys/SieQ.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/SPAN.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Spitter2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Surge.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/Synth1.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Chorus-LX.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-3.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Reverb-4.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TAL-Sampler.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/TX16Wx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Diva.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Protoverb.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Repro-1.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Repro-5.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Satin.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/TyrellN6.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebra2.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebralette.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/Zebrify.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/u-he/ZRev.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/UltraChannel.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ValhallaFreqEcho.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/ValhallaRoom_x64.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/VCV-Bridge-fx.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/VCV-Bridge.vst'... failed!
probing '/Library/Audio/Plug-Ins/VST/WaveShell1-VST 10.0.vst'... failed!
found 0 plugins
searching in '/Users/boonier/Library/Audio/Plug-Ins/VST3' ...
found 0 plugins
searching in '/Library/Audio/Plug-Ins/VST3' ...
probing '/Library/Audio/Plug-Ins/VST3/TX16Wx.vst3'... error
couldn't init module
probing '/Library/Audio/Plug-Ins/VST3/WaveShell1-VST3 10.0.vst3'... error
factory doesn't have any plugin(s)
probing '/Library/Audio/Plug-Ins/VST3/Nektarine.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Nektarine_32OUT.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/OP-X PRO-II.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/SPAN.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Surge.vst3'... failed!
probing '/Library/Audio/Plug-Ins/VST3/Zebra2.vst3'...
[1/4] 'Zebrify' ... failed!
[2/4] 'ZRev' ... failed!
[3/4] 'Zebra2' ... failed!
[4/4] 'Zebralette' ... failed!
found 0 plugins
search done
print: search_done
Scheduler queue object?
@ddw_music The time variance is because the event was triggered within the last audio block and arrives before the next block is processed. So as the beat clock is not a perfect division of the audio clock it has to skip to compensate.
You are right that event inaccuracy at that scale is not important, so Link is quite accurate enough for events.
But for the audio it is vital that the programs are in sync because our brains are wired to detect phase, but more importantly the program hasn't got a clue what to do with data that doesn't match its expectations.
It doesn't matter what the sample rate is.
The point is that it is the same for all the programs that are linked by the audio, and so they have to be in sync.
They are using that common distributed clock, with a natural sync every 64 samples, if that is the block size chosen for the audio..... so every 1.45ms roughly at 44.1 with a 64 sample buffer.
They all have to process those chunks and spit them out in sync.
It is not difficult for a modern computer to calculate time at every sample, or we would not be blessed with ASIO, DAW's and all. My DAW will show me the calculated time stamp of every sample within the 64 sample window.
Every block must pass or there would be dropouts somewhere.
The soundcard also uses the same clock as it counts it's way inexorably through the blocks.
The computer doesn't make mistakes as it counts through the blocks, unless another process blocks the calculations for too long because of a deferred procedure call. DPC latency is something to look out for when running audio applications and there are some tools available for analysis.
But the answer is no, in that there is no inaccuracy in a computer until you reach the limits of its bit depth.
David.
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
@lacuna The whole patch is recompiled within Pd and I think that although the data flow model is fantastic it makes it harder to understand the workings.
The blocks (of audio) are read, or generated, and all of the stuff that the patch needs to do to the block is done all at once to every sample in the block, and then the block is sent onwards.
So if you put [x~ 2] >> [/~ 2] then nothing is done..... the code that Pd is running has done the math and the result is "multiply sample values by one".......... so "do nothing". A complex patch will have been boiled down to "subtract x from sample1" "add y to sample2" etc...... up to sample 64, rinse, calculate the next set of additions and subtractions to apply, and do it to the next block.
Those operations..... add to sample value... or subtract from sample value.... are the only possible operations on a sample value.......
Interpolation uses adjacent sample values for the calculation, but adding or subtracting to / from the sample values is what happens when the calculations have been done.
Some objects like [x~] can be controlled by a control signal, and so the new value can only be applied at block boundaries as the control calculations are done between boundaries. The addition will be the same for every sample in the block. Pd didn't know in advance what it's next value might be, so a ramp cannot be applied across the samples in this block.
Some objects though, like [vline~] are scheduling changes of value that will happen across the block, and future blocks, and may finish at sample 43 within a block. Programmatically it is saying, as part of the whole patch "add a bit to sample 1 (if it has a +ve value or subtract if -ve)) and a bit more to sample 2 etc..... etc... and then for the next block, when the audio program runs again add even more to the 1st sample etc..... until.
So it is sample accurate.
And of course if [x~] is controlled by [vline~] it will do as it is told and be sample accurate too.
You can add a start delay to [vline~] so that it's start point is sample accurate too.
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
@Nicolas-Danet said:
control messages and compute audio vectors of the DSP graph are interleaved operations. The internal audio vector size is 64.
[64][control][64][control][64][control][64][control]
Ok, i see.
But I read control messages are first, then audio. f.e. [loadbang] is proceeded before an upcoming audio-block.
And [vline~] is calculated and "drawn" before and "modulating" the *following * audio blocks.
[control][64][control][64][control][64][control][64]
What's happen in a 1 sample reblocked subpatch? In short, instead of compute 1 vector of 64 samples, it computes 64 times following a vector of 1 sample.
And there is no way to change this interval rate of 64?
Is upsampling in a subpatch increasing the computation time-interval of control-messages?
The tricky stuff with real time audio is not to do the things fast, but do things fast at the right time. Wait the sound in, deliver the sound out, compute the next sound and wait. When i benchmark my fork for instance, most of the time is spent in sleeping!
I see. In the analog world it is very different. This is why we have the buffer-latency in digital everywhere:
...incoming audio-samples in blocks, computation, audio out, and again...
And the control-domain every 64 samples.
For me as "user" of PD this is confusing.
So every object with a [v ...] will be sampleaccurate on point in upcoming audio-blocks, as long as it is not needed more often then 64 samples later!??? i.e. as long it is not starting several times in a smaller interval then 64 samples?
PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,
Hello,
this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.
I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.
*I think it is very important to understand how timing works in detail for low-level programming … *
(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )
This is a collection of my findings regarding this topic, a bit messy and with confused questions.
I hope we can shed some light on this.
- a)
The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample
The answers where:
„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago
• 1
whale-av
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“
There is written: http://puredata.info/docs/manuals/pd/x2.htm
„2.5. scheduling
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds.
2.5.1. audio and messages
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0."
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously.
In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time.
2.5.2. computation load
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ).
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this.
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them.
2.5.3. determinism
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic.
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.)
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled.
“
[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?
How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?
While sample 1-64 are running, PD does audio only?
[metro 1 1 samp]
How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?
Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?
- b )
There are [phasor~], [vphasor~] and [vphasor2~] … and [vsamphold~]
https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors
“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share.
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“
- c)
Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)
EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)
- d)
So I looked into the sources of PD:
scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c
And found this paper
Scheduler explained (in German):
https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view
wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.
And the mainloop:
Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep
With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?
Timing-relevant objects
from iemlib:
[...]
iem_blocksize~ blocksize of a window in samples
iem_samplerate~ samplerate of a window in Hertz
------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~ time tagged trigger sig~
t3_line~ time tagged trigger line~
--------------- t3 - time-tagged-trigger ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe time tagged trigger break point envelope
t3_delay time tagged trigger delay
t3_metro time tagged trigger metronom
t3_timer time tagged trigger timer
[...]
What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?
When should I use [block~ 1 1 1] and when shouldn't I?
[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???
- c) again)
https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2
I read this in the html help for Pd:
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„
Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?
Can I control this with a startup flag or from withing PD? Or only in the sources?
There is a startup-flag for loading a different scheduler, wich is not documented how to use.
- e)
[pd~] helpfile says:
ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!
Doesn't [pd~] work within a Camomile plugin!?
How are things scheduled in Camomile? How is the communication with the DAW handled?
- f)
and slightly off-topic:
There is a batch mode:
https://forum.pdpatchrepo.info/topic/11776/sigmund-fiddle-or-helmholtz-faster-than-realtime/9
EDIT:
- g)
I didn't look into it, but there is:
https://grrrr.org/research/software/
clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.
Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.
Sample accurate control from DAW <--> PD ? With Camomile?
Hello,
i am wrapping my head around how to control PD-patches sample accurately from a DAW?
With Camomile?
As this is a bit confusing, could someone help with some light please?
For example:
** How to build a sample-accurate envelope, - triggered and modulated by a DAW? **
I am using Linux, so cross-routing with Jack is an option, too.
Probably somehow with [vline~] or [vphasor~]? This is sample accurate in the next block, isn't it? i.e. with latency-compensation in the DAW it is on point?
Open Sound Control is not sample accurate, is it? Seems like the PD-sheduler does not handle OSC synchronous!?
( How to trigger a set of control-rate objects by an audio-signal sample accurate? What would be the port / the transition between the two?
This isn't possible, is it?
I guess it is, with [pd]{ [inlet~] [block~1] [unsig~] [outlet] } and [vline~]? )
Do I need to patch the whole envelope with audio-rate objects?
i.e. [vphasor~] instead of [vline~]?
What is the way to go
to merge PD with a DAW sample-accurately?
DAW automation <--> PD control- and audio-objects.
And audio-intermodulation of DAW & PD?
abl_link~ midi and audio sync setup
Hi Folks,
I thought I’d share this patch in the hopes that someone might be able to help improve upon it. I am by no means even semi competent with PD and jumped into this task without actually bothering to learn the basics of PD or RPi, but nevertheless here we are: maybe you can share a better implementation.
Mods/experienced folks, if I am sharing irrelevant/wrong/confusing info, mea culpa and please correct me.
I wanted to make a patch for PD in Raspberry Pi that would do 3 things:
- Get the abl_link~ temp data over wifi
- Create a midi clock output using a 5-pin midi adapter (I have one of the cheapo usb-to-midi cable things here)
-simultaneously create an audio pulse ‘clock’ output such as those used by volcas, Teenage Engineering Pocket operators, and the like (I am not sure if such an audio signal over a 3.5mm jack would be hot enough to be considered a CV pulse too, maybe you can help clear that up?)
As I say, after much struggles I have globbed something together that sort of does this.
A couple of things for newcomers like myself:
The abl_link~ object in the patch isn’t initially part of the standard pure data install as I write. I was able to use deken (ie the code that powers the ‘help/find externals’ bit of PD) to look for abl_link~. Search for it. At the time of writing there is a version for Arm7 devices like the Raspberry Pi 3 which was put together by the illustrious mzero with code from antlr. Go ahead and install the abl_link~ object. (Possibly you may have to uncheck the ‘hide foreign architectures’ box to get the arm7 version to show up. This is usually a safeguard to stop users from trying to install versions of externals that won’t work on their systems. So long as you see ‘arm7’ in the description it should hopefully be the one you want) PD will ask where you want to store the external, and I would just leave it at the default unless you have a special reason to do otherwise.
To get the patch to hook up to your preferred audio and midi outputs by default you may have to take certain steps. In my version of it I have deemed the built in audio and my cheapo USB midi output to be good enough for this task.
[As part of my troubleshooting process I ended up installing amidiauto which is linked to here: https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/2
I undertook several installations in support of amidiauto which may be helping my system to see and link up my USB midi and PD, but nothing worked until I took the step in the following paragraph about startup flags in PD. (It may also be that I did not need to put in amidiauto at all. Maybe I’ll try that on another card to see if it simplifies the process. I’m saying you might want to try it without amidiauto first to see).]
Midi: - (ALSA is the onboard audio and midi solution that is part of Raspbian). To have PD use ALSA midi at the start I made the following setting in the preferences/startup dialog - within that window there is a section (initially blank) for startup flags. Here you can set instructions for PD to take note of when it starts up. I put in -alsamidi to tell it that alsamidi will be my preferred midi output. (I also took the step of going to file/preferences/midi settings, then ‘apply’ and ‘ok’ to confirm the Alsa midi ports that showed up. Then I went back to file/preferences/save all preferences. This seems to have (fingers crossed) saved the connection to my USB midi output.
Audio: I used the terminal and sudo raspi-config to set my audio out to the internal sound card (advanced options/audio/3.5mm jack). Since I had a fairly unused installation of PD I’d never asked it to do anything but work with the system defaults so getting audio out was fairly simple.
[nb I initially stuck this patch together on my Mac where everything worked pretty trouble free in terms of audio and midi selection]
About the patch. Obviously it is sort of horrible but there it is. It is a combination of stuff I cribbed from the demo example of abl_link~ in the example, and two example patches created by users NoDSP and jpg in this forum post https://forum.pdpatchrepo.info/topic/9545/generate-midi-clock-messages-from-pd/2
As well as some basic synthesis to make the bip bip noises I learned from LWMs youtube channel
https://www.youtube.com/channel/UCw5MbnaoDDuRPFsqaQpU9ig
Any and all errors and bad practice are mine alone.
The patch has some comments in it that doubtless expose my own lack of understanding more than anything. Undoubtedly many users can do a better job than I can.
Some observations on limitations/screwups of the patch:
-
If you disconnect from the stream for a bit, it will attempt to catch up. There will be a massive flurry of notes and/or audio bips as it plays all the intervening notes.
-
It doesn’t seem to be too fussy about where in the bar it is getting started (It will be "on" the beat but sometimes the ‘1’will be the ‘2’ etc. This is okay if I’m using internal sequencers from scratch (in the volca, say) but not if there is an existing pattern that I am trying to have come in 'on the 1'.
-
My solution to more detailed subdivision of bars was to make a big old list of numbers up to 32 so that abl_link~ can count up to more than 4. There’s probably a better solution for this. If you find that you need even more subdivisions because you are making some sort of inhumanly manic speed gabba, add even yet more numbers and connections.
I haven’t tested this much. And since it’s taken me the better part of 18 months to do this at all, I’m really not your guy to make it work any better. I’m posting here so that wiser souls can do a better job and maybe share what I think has the potential to be a useful midi sync tool.
I plan to revisit https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/3
for some pointers on setting this up to launch the patch at startup to give me a small, portable midi Link sync device for 5-pin and audio-pulse clocked devices.
This is my first ever bit of quasi productive input to any technical community (mostly I just hang around asking dumb questions… So be kind and please use your giant brains to make it better) I look forward to spending some time learning the basics now. link-sync.pd
Web Audio Conference 2019 - 2nd Call for Submissions & Keynotes
Apologies for cross-postings
Fifth Annual Web Audio Conference - 2nd Call for Submissions
The fifth Web Audio Conference (WAC) will be held 4-6 December, 2019 at the Norwegian University of Science and Technology (NTNU) in Trondheim, Norway. WAC is an international conference dedicated to web audio technologies and applications. The conference addresses academic research, artistic research, development, design, evaluation and standards concerned with emerging audio-related web technologies such as Web Audio API, Web RTC, WebSockets and Javascript. The conference welcomes web developers, music technologists, computer musicians, application designers, industry engineers, R&D scientists, academic researchers, artists, students and people interested in the fields of web development, music technology, computer music, audio applications and web standards. The previous Web Audio Conferences were held in 2015 at IRCAM and Mozilla in Paris, in 2016 at Georgia Tech in Atlanta, in 2017 at the Centre for Digital Music, Queen Mary University of London in London, and in 2018 at TU Berlin in Berlin.
The internet has become much more than a simple storage and delivery network for audio files, as modern web browsers on desktop and mobile devices bring new user experiences and interaction opportunities. New and emerging web technologies and standards now allow applications to create and manipulate sound in real-time at near-native speeds, enabling the creation of a new generation of web-based applications that mimic the capabilities of desktop software while leveraging unique opportunities afforded by the web in areas such as social collaboration, user experience, cloud computing, and portability. The Web Audio Conference focuses on innovative work by artists, researchers, students, and engineers in industry and academia, highlighting new standards, tools, APIs, and practices as well as innovative web audio applications for musical performance, education, research, collaboration, and production, with an emphasis on bringing more diversity into audio.
Keynote Speakers
We are pleased to announce our two keynote speakers: Rebekah Wilson (independent researcher, technologist, composer, co-founder and technology director for Chicago’s Source Elements) and Norbert Schnell (professor of Music Design at the Digital Media Faculty at the Furtwangen University).
More info available at: https://www.ntnu.edu/wac2019/keynotes
Theme and Topics
The theme for the fifth edition of the Web Audio Conference is Diversity in Web Audio. We particularly encourage submissions focusing on inclusive computing, cultural computing, postcolonial computing, and collaborative and participatory interfaces across the web in the context of generation, production, distribution, consumption and delivery of audio material that especially promote diversity and inclusion.
Further areas of interest include:
- Web Audio API, Web MIDI, Web RTC and other existing or emerging web standards for audio and music.
- Development tools, practices, and strategies of web audio applications.
- Innovative audio-based web applications.
- Web-based music composition, production, delivery, and experience.
- Client-side audio engines and audio processing/rendering (real-time or non real-time).
- Cloud/HPC for music production and live performances.
- Audio data and metadata formats and network delivery.
- Server-side audio processing and client access.
- Frameworks for audio synthesis, processing, and transformation.
- Web-based audio visualization and/or sonification.
- Multimedia integration.
- Web-based live coding and collaborative environments for audio and music generation.
- Web standards and use of standards within audio-based web projects.
- Hardware and tangible interfaces and human-computer interaction in web applications.
- Codecs and standards for remote audio transmission.
- Any other innovative work related to web audio that does not fall into the above categories.
Submission Tracks
We welcome submissions in the following tracks: papers, talks, posters, demos, performances, and artworks. All submissions will be single-blind peer reviewed. The conference proceedings, which will include both papers (for papers and posters) and extended abstracts (for talks, demos, performances, and artworks), will be published open-access online with Creative Commons attribution, and with an ISSN number. A selection of the best papers, as determined by a specialized jury, will be offered the opportunity to publish an extended version at the Journal of Audio Engineering Society.
Papers: Submit a 4-6 page paper to be given as an oral presentation.
Talks: Submit a 1-2 page extended abstract to be given as an oral presentation.
Posters: Submit a 2-4 page paper to be presented at a poster session.
Demos: Submit a work to be presented at a hands-on demo session. Demo submissions should consist of a 1-2 page extended abstract including diagrams or images, and a complete list of technical requirements (including anything expected to be provided by the conference organizers).
Performances: Submit a performance making creative use of web-based audio applications. Performances can include elements such as audience device participation and collaboration, web-based interfaces, Web MIDI, WebSockets, and/or other imaginative approaches to web technology. Submissions must include a title, a 1-2 page description of the performance, links to audio/video/image documentation of the work, a complete list of technical requirements (including anything expected to be provided by conference organizers), and names and one-paragraph biographies of all performers.
Artworks: Submit a sonic web artwork or interactive application which makes significant use of web audio standards such as Web Audio API or Web MIDI in conjunction with other technologies such as HTML5 graphics, WebGL, and Virtual Reality frameworks. Works must be suitable for presentation on a computer kiosk with headphones. They will be featured at the conference venue throughout the conference and on the conference web site. Submissions must include a title, 1-2 page description of the work, a link to access the work, and names and one-paragraph biographies of the authors.
Tutorials: If you are interested in running a tutorial session at the conference, please contact the organizers directly.
Important Dates
March 26, 2019: Open call for submissions starts.
June 16, 2019: Submissions deadline.
September 2, 2019: Notification of acceptances and rejections.
September 15, 2019: Early-bird registration deadline.
October 6, 2019: Camera ready submission and presenter registration deadline.
December 4-6, 2019: The conference.
At least one author of each accepted submission must register for and attend the conference in order to present their work. A limited number of diversity tickets will be available.
Templates and Submission System
Templates and information about the submission system are available on the official conference website: https://www.ntnu.edu/wac2019
Best wishes,
The WAC 2019 Committee
Possible audio file playback methods
@Transcend Ahh..... that is where the confusion arises. What is being read is individual samples.... at 44100Hz sample rate there are 44100 every second. The pitch is heard because of the rate at which they rise and fall in value.
In Pd a sine wave at 100 Hz would have a sample value of zero (maybe, it depends at what time the wave starts) at index 0, and then rising sample values to a value of 1 at sample number 110 (more or less) falling back to a sample value of 0 at sample 220, continuing to fall to -1 at sample 330 and then rising back to a value of zero at sample number 441....... etc. etc.
When those values are read by [tabread4~] the output would....... eventually, once it gets to your speakers..... push and pull the speaker smoothly 100 times a second, and be heard as 100Hz. Depending on the bit-depth of the dac the actual sample values later in the chain will be much larger, but Pd max/min values are +1/-1 at the output to the [dac~]. Your soundcard and Pd take care of that automatically.
If there is another sound, say at 1KHz., that would modulate that 100Hz wave..... it would look like a ripple on the 100Hz wave........ and so on. A music track will look a real mess when you look at it, with only loud / quiet parts really recognisable. But our ears, or more especially our brains, can make total sense of it.
Samplerate (audio) objects are used to set the indexes because they send a value at the samplerate...... so 44100 times a second...... so every single index is sent to [tabread4~]
Digital audio (FFT) is fiendishly complicated to understand, but this gets you quite a long way into it in only a few minutes........ https://medium.com/@djtech42/explanation-of-sample-rate-in-digital-audio-and-breakdown-of-misconceptions-38f912fb3b1f
Actually it gets you a very long way toward a good understanding in just a few minutes.......
David.
Recording input signal continously
You should be able to use writesf~ to write continuously to disk during performance.
In the main Pd thread (which is the one in which your patch is running) writesf~ will just write samples to a buffer every block, plus some other bookkeeping stuff. Reading an array of samples and writing it to another array is about the simplest thing a tilde object can do in Pd, so it should be realtime safe.
There's a secondary (i.e., child) thread that actually writes the data to the disk. For simplicity, the code in the child thread will write data using a blocking system call. But even when writing to the disk takes longer than the time it takes to compute a block of samples in Pd, that's ok. Pd will just add more samples to the buffer, and the child thread will eventually catch up and write everything to disk. Your patch should continue computing audio in realtime with no dropouts.
Using the current settings in Purr Data, it looks like you will start approaching a catastrophe if the child thread falls behind schedule by about 6 seconds. Operating systems don't technically make any guarantee about the maximum time a write to the disk. However, in practice if it takes that long for your computer to write some bytes to disk you've probably got bigger problems with your system. So in practice, you should be able to continuously record to disk without a problem.
Also worth noting-- if Pd itself happens to take too long to compute audio (e.g., your patch uses too much CPU and you hear dropouts) then writesf~ will actually continue to work deterministically (i.e., you'll get the proper audio signal written to disk). This is because the child thread will wait until it has sufficient number of samples to write to the file. (Unlike your soundcard which has to deliver something on a clock, which is just zeros if there was a problem and Pd missed the deadline to deliver audio.)
Edit: clarification
Edit: another set of clarifications