Looking for dark layout - is it possible?
@ejoo Hi, currently vanilla doesn't support tk color hooks. However, I have a branch which does that is only a few commits behind HEAD.
https://github.com/sebshader/pure-data/tree/colors
(The names are somewhat different than in extended, as discussed in this pr:)
https://github.com/pure-data/pure-data/pull/196
you have to compile yourself.. there is an example scheme in doc/7.stuff/colors-plugin.txt (change the extension to .tcl and put it in your path, and you can then edit (or remove for defaults) the values below line 43:
array set ::pd_colors {
e.g.
array set ::pd_colors {
canvas_fill "Black"
signal_cord "IndianRed"
signal_iolet "IndianRed"
msg_cord "DodgerBlue"
msg_iolet "DodgerBlue"
atom_box_fill "MintCream"
msg_box_fill "MintCream"
obj_box_fill "MintCream"
obj_box_outline "Black"
msg_box_outline "Black"
atom_box_outline "Black"
graph_outline "Black"
}
there are also more colors than were settable in extended including colors for GOP box, array values, console window, help browser, and [text] object windows
I have an osx binary btw if anyone wants one
edit: graph_outline as black? .. maybe that was different in extended but it doesn't show up against the black canvas
& I would also recommend setting "comment" to MintCream or something
how to limit DS array value range
@ingox yeah, but that's what i've been looking for - i didn't think of using plot for limiting the values. in this case, i don't need the index of the modified array element, because the values will triggered by a sequencer, that just iterates through the array. i store all the values at once with a combo of [array get] / [array set].
what i still find unsatisfying is, that i don't get it to work, that the values get stored in a hidden table, that saves the contents with the patch, right after i changed a value. at the moment, i use [mousestate], wich let's me store the values, just when i release the mousebutton. i'd love to get this in vanilla, but it seems that the data structures only give me click events, but not when the mousebutton is released. but ok, thats off topic now.... if someone knows a good workaround though, don't hesitate to reply! however, thank you very much!
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
Wind and Rain....
after years of "pd-abstinence" and not doing anything dsp-related at all, i built a new patch in the past few days, which is roughly inspired by "space drones" from NI Reaktor. the patch can be used to create wind- and rain-like soundscapes or something like this...
my main intention was to get into pd again and learn a bit about data structures to visualize sound particles and figure out, how the [clone] object works, which - afaik - was'n available last time i patched with pd.
i built a similar patch years ago, but i remember that voice management was a real pain in the ass, so i had to use dynamic patching for this, etc.
now, there's still a lot to do:
- adjust parameters and their relations
- gain compensation for high filter q
- enhance visualisation of sound particles
- and a lot more....
you will need to get some external libraries in order to get the patch working, i guess mainly zexy, cyclone and else.... there's an additional compressor external (t_comp~) in the abs-folder which is the stereo compressor from the FAUST libraries. since i'm on linux i compiled the external for osx and win32 via the FAUST online editor and couldn't test them afterwards - i hope they work for you... EDIT: here's the DSP file, for those who want to compile it with Faust Works or whatever.... t_comp.dsp
however, suggestions on how to enhance the patch are welcome! thanks in advance for trying!
EDITS:
-
winds2_r001.zip
a few changes in signal flow, added a master volume with vu meter, fixed a bug (double triggered notes), put reverb after compressor -
winds2_r002.zip
now in one-window-mode
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]
Ubuntu 18, how to update Gem?
@whale-av "But you might need some libraries installed too....... README.linux ..... ?
The readme is from an older attempt at 0.94, but there is a bit about libraries for some video formats."
Aha... I did find, then, that pix_film also failed to load mp4 files. That was resolved by the following:
aptitude install libgl-dev libglu-dev
aptitude install libxxf86vm-dev
aptitude install ftgl-dev
aptitude install libtiff3g-dev libjpeg62-dev libmagick++9-dev
aptitude install libmpeg3-dev libavifile-0.7-dev libquicktime-dev libdv4-dev
Then make clean, ./autogen.sh, ./configure, make.
But that didn't fix the pix_video problem.
At this point I'll take it to the Gem bug tracker. I follow the given build instructions and at least one feature is missing, which is at least a documentation bug.
hjh
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.
installing PD-extended onto the raspberry pi 3
Hello everyone!
I following the installing instructions for Pd extended for Raspberry Pi
and when I run this command:
$ sudo dpkg -i Pd-0.43.3-extended-20121004.deb
I keep getting this error:
Selecting previously unselected package pd-extended.
(Reading database ... 57768 files and directories currently installed.)
Unpacking pd-extended (from Pd-0.43.3-extended-20121004.deb) ...
dpkg: dependency problems prevent configuration of pd-extended:
pd-extended depends on libfftw3-3; however:
Package libfftw3-3 is not installed.
pd-extended depends on libftgl2 (>= 2.1.3~rc5); however:
Package libftgl2 is not installed.
pd-extended depends on libglu1-mesa | libglu1; however:
Package libglu1-mesa is not installed.
Package libglu1 is not installed.
pd-extended depends on libgsl0ldbl (>= 1.9); however:
Package libgsl0ldbl is not installed.
pd-extended depends on libjack-jackd2-0 (>= 1.9.5~dfsg-14) |
libjack-0.116; however:
Package libjack-jackd2-0 is not installed.
Package libjack-0.116 is not installed.
pd-extended depends on liblua5.1-0; however:
Package liblua5.1-0 is not installed.
pd-extended depends on libmp3lame0; however:
Package libmp3lame0 is not installed.
pd-extended depends on libquicktime2 (>= 2:1.2.2); however:
Package libquicktime2 is not installed.
pd-extended depends on libspeex1 (>= 1.2~beta3-1); however:
Package libspeex1 is not installed.
dpkg: error processing pd-extended (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for desktop-file-utils ...
Processing triggers for shared-mime-info ...
Errors were encountered while processing:
Has anyone else encountered this problem?
If so, any suggestions?
thanks,
J
Playback self recorded file in table
@whale-av Well. At first I thought I was damned
This must be like the most stupid rookie mistake of them all - no number means 0, could have thought of that...
BUT! Thank you so so so so much! I cannot describe how grateful I am - these are mistakes I could never spot myself, when I am so deep in the process - thank you so much, I was really desperate already
The abstraction is the next step - now I am looking forward to creating it! I'll think about your advises while building the abstraction!
Thank you so much David!
Maggie