Pd FLOSS Manual, what to do with it?
@whale-av said:
I cannot see how changing it from Extended to PurrData would be helpful.
This thread relates to Pure Data itself (a.k.a. Pd Vanilla and not any fork of Pd) and has the goal to organize its documentation in a sensible way. And yeah, like I said, it'd add more noise (the opposite of what we want here), and a new Purr Data manual can be made at any point (and that is a separate discussion). The Pure Data manual can easily point to forks, that about that, have links to them and stuff..
Yes yes yes... a new Vanilla Floss with OSC explained properly...... (good luck with that) but you are going to make a lot of work for us on the Forum.
A 'Vanilla' Floss manual can include externals like mr peach quite easily and we could retain the same thing there... no worries bro
@whale-av said:
know there is a constant pushback against Extended but I still cannot understand why so many are set against it when it was really just a Vanilla++.
We all loved Extended and cried a lot when it passed away.
I wonder whether your project should really include a new 64-bit Pd Extended with all the new libraries you have all been working so hard to provide?
The argument that "it is no longer maintained" would then hold no water...!!
Dear friend, Extended died, it's dead, get over it creating yet a new fork of Pd is out of the question here, and resurrecting Extended from the dead would make the argument that it's dead hold no water, of course, but we'd need to change reality for that.
Not sure whoever still needs to hear this, but Don't expect anyone to bring Extended back to life. If it didn't happen in the mid 10s, it's not happening now, no chance! The thing is that you can now just easily install libraries in Vanilla and I think it's a much better model that even makes me celebrate the demise of Extended as a blessing in disguise. And I think it's kind of a curse that there are still alternatives to it that keep its ghost around to haunt us. But anyway, it's not the point of this thread to discuss the ever lasting issue of us being widowed by Extended
Pd FLOSS Manual, what to do with it?
Folks, we're on a roll debating all things related to Pd documentation here and there and I'm now focusing on the Pd FLOSS Manuals issue.
Pd has this very famous and long lasting FLOSS Manual. It's old and it tells you how to instal Pd Extended 0.39! So, it's from the extended era and still references to 'extended objects'. For what I see, it was a Manual that came to be in the Extended era as a Manual to it. Back in the day we basically all used just Extended anyway and were mostly oblivious to Pd Vanilla and its manual.
And by Pd's manual, I mean http://msp.ucsd.edu/Pd_documentation/index.htm - I know that's called 'Pd Documentation', and that it is confusing, cause it actually is an 'html Manual' and it refers to itself as "this html manual". Anyway, this is also something I brought up on github and is not the issue here..
The point is that there's a conflict and I guess this made sense then, but it's a problem nowadays. A documentation noise problem. Lots of people seem to get to it and consider it "the manual for Pd". We're still struggling with a post Pd Extended issue and what was consolidated in its era but now sits as ruins. Actually, Pd Vanilla's manual also refers to FLOSS Manuals. But these days we have something weird, which is simply the fact that Pure Data has these two manuals. One is the official one, included as part of Pd Vanilla and its documentation, and this other one, which is terribly outdated and actually refers to this unsupported and abandoned fork of Pd.
But the point is, one software cannot have two concurring Manuals, even if both are up to date - that'd be silly. The point of FLOSS is to provide the one and only official and single Manual for a piece of software. See the problem? Csound uses FLOSS Manuals as a place to provide its official manual. It's clearly linked in csound.com. Csound also has the 'Canonical Csound reference manual', which is actually something else and not to be confused with "The" manual they provide in FLOSS.
So, my point is we have to get rid of one of them and have a single official one.
Should we then remove the included and official manual from Pd and 'move it' to FLOSS and completely overhaul that online version?
Or just get rid of the FLOSS version? Well, that is there, and people know it. Burn it down, purge and disappear with it would be bad.
Well, I don't know, so I'm asking...
Another scenario is that FLOSS can still be around, of course, but as a museum piece, for those interested in web archeology, as extended is now an archeological piece of software. No one touches it, it stays there, but we try to make it clear how that is an old, outdated, unofficial and that Pd has its own 'real manual. This would help a lot. Or... also, treat it for what it is, a manual reference for Pd Extended, not Vanilla, and make it clear how Pd Extended is abandoned and so is this manual.
Other than these, the only option I see is we maintain and update these two manuals somehow. And I already said how I think that's pointless. I also don't know who'd do that... but maybe there'd be a way to manage them as two clearly distinct guides. One would be the 'Canonical Vanilla Manual' and the other could be 'The Pure Data Manual' (or some other name)? The question would be, why to do that? What is the advantage in keeping another FLOSS version around?
The thing I can think people like about the FLOSS version is:
- A: A friendlier look for beginners;
- B: A nice beginner level tutorial;
- C: Support for many externals, external libraries, how to use Arduino and stuff (more as a tutorial than a 'manual');
These can all be compensated. With 'A)', we can try and make the Pd manual look nicer maybe? As for the rest, what really seems to be the substance of this is the fact that it serves as a tutorial.
Well, a tutorial is not necessarily a "Manual".
We can add tutorials to Vanilla too... actually, even though it's based on Extended, many of the examples there are 'vanilla', so they can be easily ported and shipped as part of Vanilla!
As for tutorials that use externals. Well, they would really benefit from an update. But a tutorial is a tutorial, this could live somewhere else.
By the way, tutorials can easily be uploaded to deken and be available from there. You'd have a tutorial that relies on externals, but that's ok too (my live electronics tutorial comes as part of the ELSE download)... just give instructions in the tutorial on how to install the needed libraries from deken as well...
But if the case is made that we should really keep FLOSS and update it. Well, maybe we could manage and do that, taking care on how to not overlap even know I don't know who'd do it, but it'd mean completely rewrite from scratch and get rid of some of the stuff. That's bad too, as the old version would be lost (so have it sit as an 'old extended manual'?).
So, in short, possible scenarios include:
- Forget about floss, tell it's outdated (rename it to pd extended manual maybe), focus on Vanilla's manual. Bring stuff we miss and like from FLOSS to current Pd in some new form.
- 'Move' Pd's manual to a new FLOSS incarnation
- Keep and manage two versions
My thoughts on these are here, and I think the best scenario is number "1)"
Any other thoughts?
Cheers
Dynamic amplifier/overdrive (with sag and some other tricks). ThurboDrive!
@Booberg Can you list the dependencies?
... couldn't create
tanh~
... couldn't create
z~
... couldn't create
range~
... couldn't create
dA
... couldn't create
number~
... couldn't create
array: no method for 'saved'
number~
... couldn't create
array: no method for 'saved'
brickwall~ 18500
... couldn't create
brown~
... couldn't create
bandstop~ 1050 0.3
... couldn't create
lag~ 384 768
... couldn't create
>~ 0.5
... couldn't create
slide~ 10 -0.5
... couldn't create```
Question about Pure Data and decoding a Dx7 sysex patch file....
Hey Seb!
I appreciate the feedback
The routing I am not so concerned about, I already made a nice table based preset system, following pretty strict rules for send/recives for parameter values. So in theory I "just" need to get the data into a table. That side of it I am not so concerned about, I am sure I will find a way.
For me it's more the decoding of the sysex string that I need to research and think a lot about. It's a bit more complicated than the sysex I used for Blofeld.
The 32 voice dump confuses me a bit. I mean most single part(not multitimbral) synths has the same parameter settings for all voices, so I think I can probably do with just decoding 1 voice and send that data to all 16 voices of the synth? The only reason I see one would need to send different data to each voice is if the synth is multitimbral and you can use for example voice 1-8 for part 1, 9-16 for part 2, 17-24 for part 3, 24-32 for part 4. As an example....... Then you would need to set different values for the different voices. I have no plan to make it multitimbral, as it's already pretty heavy on the cpu. Or am I misunderstanding what they mean with voices here?
Blofeld:
What I did for Blofeld was to make an editor, so I can control the synth from Pure Data. Blofeld only has 4 knobs, and 100's of parameters for each part.... And there are 16 parts... So thousand + parameters and only 4 knobs....... You get the idea
It's bit of a nightmare of menu diving, so just wanted to make something a bit more easy editable .
First I simply recorded every single sysex parameter of Blofeld(100's) into Pure data, replaced the parameter value in the parameter value and the channel in the sysex string message with a variable($1+$2), so I can send the data back to Blofeld. I got all parameters working via sysex, but one issue is, that when I change sound/preset in the Pure Data, it sends ALL parameters individually to Blofeld.... Again 100's of parameters sends at once and it does sometimes make Blofeld crash. Still needs a bit of work to be solid and I think learning how to do this decoding/coding of a sysex string can help me get the Blofeld editor working properly too.
I tried several editors for Blofeld, even paid ones and none of them actually works fully they all have different bugs in the parameter assignments or some of them only let's you edit Blofeld in single mode not in multitimbral mode. But good thingis that I actually got ALL parameters working, which is a good start. I just need to find out how to manage the data properly and send it to Blofeld in a manner that does not crash Blofeld, maybe using some smarter approach to sysex.
But anyway, here are some snapshots for the Blofeld editor:
Image of the editor as it is now. Blofeld has is 16 part multitimbral, you chose which part to edit with the top selector:
Here is how I send a single sysex parameter to Blofeld:
If I want to request a sysex dump of the current selected sound of Blofeld(sound dump) I can do this:
I can then send the sound dump to Blofeld at any times to recall the stored preset. For the sound dump, there are the rules I follow:
For the parameters it was pretty easy, I could just record one into PD and then replace the parameter and channel values with $1 & $2.
For sound dumps I had to learn a bit more, cause I couldn't just record the dump and replace values, I actually had to understand what I was doing. When you do a sysex sound dump from the Blofeld, it does not actually send back the sysex string to request the sound dump, it only sends the actual sound dump.
I am not really a programmer, so it took a while understanding it. Not saying i fully understand everything but parameters are working, hehe
So making something in Lua would be a big task, as I don't know Lua at all. I know some C++, from coding Axoloti objects and VCV rack modules, but yeah. It's a hobby/fun thing I think i would prefer to keep it all in Pure Data, as I know Pure Data decently.
So I do see this as a long term project, I need to do it in small steps at a time, learn things step by step.
I do appreciate the feedback a lot and it made me think a bit about some things I can try out. So thanks
play random file from folder
Hi David,
I downloaded the externals you mentioned.
Opening the tracklist button i get:
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
opening cart5 i get:
invert
... couldn't create
count 1
... couldn't create
l2s
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
l2s
... couldn't create
initbang
... couldn't create
l $1
... couldn't create
print_long
... couldn't create
counter
... couldn't create
Sorry that I have little experience and can't understand what to do in these cases.
It looks like Î should have some extra patches. For example initbang is not recognized; same for print_long.
The tracklist opens the directory but recognizes no .wav files (i have replaced the spaces with underscores).
I also send my patch in attachment. It is quite messy, but working for files named m1, m2, v1, v2, etc. the idea is simple, all my .wav files have 10 seconds lenght, and there will be a superimposition of two .wav files at the same time, when block A is at 5 seconds, block B enters, and when block A finishes it goes to folder A to get another file.
But if you help me on the files you sent I can adapt your code to my patch, I think I could work it out.
Thanks in advance
Nando
blocks.pd
data structures - xy-pad in value range 0-1
oh, great - thanks for all the replies!
@ingox
Is it possible that you are using @Balwyn's xy-patch
no, not this patch, but yeah, i was inspired by another patch i found here somewhere in the forum... don't remembr exactly which one, but this got me started - i'm still trying to get into data structures, which is quite hard sometimes, so it's really good to have some patches to get started with...
It is that data structures get an invisible dragging area of 10 or 12 pixels squared. This is not documented and i don't remember the exact circumstances how the area is created. But the dragging area is unfortunately independent from the displayed form in size, so a bigger form can not be dragged at any point. Hope that helps a little bit.
yeah, i was afraid, this could be the answer!
@Balwyn said:
@toxonic just multiplying the outputs by 0.01 gives the same result
yes, correct - it's not a big deal to convert the output into any range, but i just hoped to keep things simple....
@Balwyn said:
@toxonic You may get some insight into using the hotspot without a pointer with this offering I uploaded a few years ago,
https://forum.pdpatchrepo.info/uploads/files/1498974324729-xydrag.zip
The template is a little confronting but shows that by using just one xy pair (px and py) multiple nodes can be created using scaling and constraining (eg px(-100:100)(20:20) py(-100:100)(-20:-20)).
the x and y output from the grid is interpreted as greater or smaller than the previous which activates a plus or minus counter for the output values
oh, sweet jesus, this is a huge template within the [pd template] patch.... i have to go to work now, but i'll try to figure it out, when i'm at home again!
thank you all for your answers, great forum!
[pix] + [pix-ds] Draw images directly onto the patch (vanilla)
The abstraction [pix] allows to draw images that are in plain PPM format directly onto the patch. Any image can be converted into PPM using graphic software like GIMP or others. The images are displayed in full RGB color.
There is also [pix-ds], which is much faster, as it uses data structures. It only uses the reduced color space of data structures. [pix-ds] still has a border on the right and bottom. Sorry!
[pix] uses canvases to create the image. Depending on the image size, the number of canvases can get very large and it may take a long time to display the image and also to close the patch! [pix-ds] will run into the same issues. Images will also add up! Use with care!
Due to the limitations of the Pd GUI this is just a nerdy fun project and may not be really usable for a serious task.
Anyhow, enjoy!
Download: pix.zip
BlurPD - digital logic framework system for Pure Data [v3]
BlurPD is a framework system to extend Pure Data with the ability to make
digital logic circuits while taking advantage of the DSP capabilities of Pure Data. In order to design and simulate interesting circuits, ASIC chips, DSP processors or entire CPU's, all in Pure Data. It is made from jucy fundamental modules (Lego blocks) that when put together turn Pure Data into a madness of bits ...
Bug Fixes & Notes [v3]
Modules [v3]
- GATES : not,and,nand,or,nor,xor,xnor,cfg,icfg,dna,ro,and3,or3,nand3,nor3,xor3,xnor3
- PLEXERS : 2x1multiplexer,1x2demultiplexer,1x2decoder
- MATH : adder,subtractor,multiplier,divider,comparator,comparator2
- IC : bpd1g8n (integrated 8xNAND gates)
- TOOLS : redled,blueled,greenled,yellowled,magentaled,cyanled,sigv,pininv,gateanalyer
ledmatrix,controller,adipswitch,vled,hexdisplay,sigbridge,pinanalyzer - WIRING : pininput,pinoutput,pin0,pin1,dipswitch,idipswitch
- MODULES : the core library for BlurPD built-in modules
- ICMODULES : the core library for "IC" modules
- DSP : btom,sin~,pha~,ipha~,cos~
- DSPTOOLS : scope~
New Stuff [v3]
- Changes to the Help system. Better GUI and integration [v3]
patch download
BlurPDv3-[3-7-2020].zip
BlurPD archive (older versions)
BlurPDv2.9-[3-3-2020].zip
BlurPDv2.8-[3-3-2020].zip
BlurPDv2.7-[3-3-2020].zip
BlurPDv2.6-[3-1-2020].zip
BlurPDv2.5-[2-29-2020].zip
BlurPDv2.4-[2-27-2020].zip
BlurPDv2.3-[2-26-2020].zip
BlurPDv2.2-[2-25-2020].zip
Multibit modules for more complex circuits [v3]
4-bit Boran-Tsung function using a 4-bit ALU (arithmetic logic unit) circuit made with BlurPD [v3]
4-bit Xi'n function using a 4-bit ALU circuit made with BlurPD [v3]
Snapshot of the modules system and help system [v3]
Making generative sounds using new DSP modules [v2.9]
Polymorphic circuit [v2.7]
Application 1 of BlurPD system from [v2.3]
Application 2 of BlurPD system from [v2.3]
Hexadecimal display [v2.3]
The Ancients [v2.2]
Complex analysis using a DIP-switch analyzer [v2.1]
DIPSwitch from [v2.0]
The miniwoog
Hello! Trying to get this working and installed PD-Extended using the Windows installer here. However, I'm still missing a lot of objects needed to run the patch. @whale-av suggested using the help browser to get the right library- does anyone know what library/-ies I need to get these objects?
expr, expr~, fexpr~ version 0.4 under GNU General Public License
list-extend
... couldn't create
list-minmax
... couldn't create
l
... couldn't create
pink~
... couldn't create
pmenu v0.31 by tof
getdir
... couldn't create
splitfilename .
... couldn't create
splitfilename /
... couldn't create
splitfilename .
... couldn't create
splitfilename /
... couldn't create
getdir
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
list-drip
... couldn't create
demux
... couldn't create
midiparse
... couldn't create
list-extend
... couldn't create
list-dripslow
... couldn't create
l
... couldn't create
l
... couldn't create
once
... couldn't create
demux
... couldn't create
demux 1 2 3 4
... couldn't create
list-extend
... couldn't create
list-delete
... couldn't create
list-find
... couldn't create
demux
... couldn't create
l
... couldn't create
l
... couldn't create
list-nth
... couldn't create
l
... couldn't create
mux 1 2
... couldn't create
demux
... couldn't create
list-sort
... couldn't create
mux 1 2
... couldn't create
midiin: windows: not supported
tanh~
... couldn't create
l2s -
... couldn't create
time
... couldn't create
date
... couldn't create
getdir
... couldn't create
z~ 64
... couldn't create
z~ 64
... couldn't create
MouseState
... couldn't create
l2s
... couldn't create
list-idx
... couldn't create
list-delete 0 1
... couldn't create
deny 0
... couldn't create
demux
... couldn't create
list-idx
... couldn't create
list-delete 0 1
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux 0 1 2
... couldn't create
demux
... couldn't create
demux
... couldn't create
list-drip
... couldn't create
colorpanel
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
demux
... couldn't create
pmenu: 'default' is not an available option.
signal outlet connect to nonsignal inlet (ignored)
signal outlet connect to nonsignal inlet (ignored)
signal outlet connect to nonsignal inlet (ignored)
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.