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.

Here is the patch that I have been working on for the past few months. OverBlast is a sampler sequencer that will be used as the UI for a DIY midi workstation with a Raspberry pi. And now with a lot of help from people in this forum I have been able to play midi sequences from midi hardware which was a huge step in its development process. Boy let me tell you learning puredata has been an experience that taught me to learn from the headaches and appreciate the highs. lol

In its current state I have been At this point there are a few known bugs. listed below.

Known Bugs

• Sample Editor - Truncate btn dose not work correctly. saves whatever is in soundfiler buffer should clip start and end positions.
• Sample Editor - Loop playback toggle dose not do anything at the moment. sample will automaticly loop.
• Sample Editor - When start and end positions are adjusted the patch will crash the next time the sample is played or looped
• Sample Editor - Loop playback toggle dose not do anything at the moment. sample will automaticly loop.
• Sample Editor - Time stretch dose not to any thing. pitch slider will only changes the pitch. Time stretch should take in account the pitch and bmp to make it a true time strecth.
• Sample Editor - Loop playback toggle dose not do anything at the moment. sample will automaticly loop.
• Sample Editor - Export as Wave dose not do anything at the moment.
• Sequencer dose not work.. WIP contains only ui design
• Song builder does not work. WIP contains only ui design

With that said if you wish to play around with this patch it will more then likely crash while using the sample editor if the start and end positions are adjusted as there is still work to be done with it. The only thing that works in the sample editor is the sample recorder. You are able to record sample and import them to the sample editor to be edited but you cant actually make edits yet.

So why release the patch in this state? Well i could use some feedback and peoples thoughts on the workflow. And simply if there is anyone out there that is interesting in lending a hand in its development. What can you do with it?

You can load samples to the mixer and play sequences from your midi hardware. Record samples from a mic to the sample editor and play them (Dont adjust the start and end positions) it may crash.

Again the song builder and sequencer do not work they are simply ui designs. Be warned if you are going to dive int he sample editor is very messy as it was when I was doing the majority of my exploration/noobing into puredata. I have been slowly cleaning it up.

I should mention you can learn midi notes then save them as a preset the pad controller is fully functional.

Sadly I cant make a video my laptop locks up when I try to use obs or xsplit.

The main patch is OverBlast.pd inside of the zip

OverBlast-SuperAlpha.zip

Apologies for cross-postings

Fifth Annual Web Audio Conference - 2nd Call for Submissions

https://www.ntnu.edu/wac2019

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

@jeffgrips I have it running with vanilla in Windows7.... but it was hard...... and it's a long story....
I cannot see any reason that it would not work for widows10.
I have not found any other easier better solution.
(((SEE below though for the fact that the -lib needs to be declared...!
That could be your only problem? But I doubt it..!!! )))

I used the 64-bit GEM from here (0.94-test3.zip)..... https://github.com/avilleret/Gem/releases/

I unzipped it and put it in a folder (which I called "dot") on my desktop.

Because I am using many different versions of Pure Data I left it there, and I start Pd with a shortcut that also points to the GEM folder and loads it as a library (It has to be loaded at startup as a library...... and that could be why you don't have it working.... but probably not...).
This is the contents of the line "target" in the shortcut.......

"C:\Users\David\Desktop\Pd Vanilla\pd-0.47-1.msw\pd\bin\pd.exe" -lib C:\Users\David\Desktop\dot\0.94-test3/Gem -font-size 10 -font-face "Consolas"

Be careful with forward / backward slashes.

I am pretty sure that I tipped the contents of the "QT" folder out into the "0.94-test3 folder" where gem.dll is (from within the "QT" folder inside "0.94-test3").
If you find some .dlls are missing then post back with a list, and I can upload them....... but you might not have the correct C++ redistributables from Microsoft.

But if you want to start Pd normally by double-clicking a patch then you will need to declare the library in Pd.. edit....preferences.... startup......
If you have GEM in the extra folder you should only need to put "-lib Gem" where you see that I have put "-noautopatch".......

The gem abstractions could not be found though (the "parts of Gem... .like [pix_image] pix_video] [gemwin] etc. worked fine) I copied the contents of the Gem folder from "extended" into a folder on the desktop called "GemAbstr" and set a path to it in Pd preferences.
I removed gem.dll from that folder (no conflicts....!).
The abstractions now create, but the help files for embedded objects cannot be found (different "search" for embedded objects) so I have to open my "GemAbstr" folder and open them manually.

Everything works. All the patches from https://puredata.info/downloads/extended-view-toolkit create and run correctly. The camera on my computer even works (I had never had it working before).
And it works with Spout.

If you go this route then I wish you good luck.......

@zerino has confirmed that it can work with widows10........ https://forum.pdpatchrepo.info/topic/11450/pix-and-geometric-objects-not-being-loaded-in-pd-vanilla/7
........and resolved the "help" file problem.....

For the time being you are lucky that you are using Windows.
This solution is not available for other systems.
David.

@Johnny-Mauser Are you still on OSX 10.8?

At some point in the future I'm going to have to drop both WinXP and OSX 10.8 support because current versions of the GUI toolkit don't support those systems anymore. It's not a priority right now, but I am seeing various speedups and new features in the newer GUI toolkit versions that will help improve Purr Data. I'll post a message about it to the list before it happens, but when those features hit a critical mass I'll need to make the switch.

@robertsyrett A few things Purr Data has which Pd Vanilla doesn't:

• infinite undo
• GUI presets (skins)
• introspection objects (which can be used to get abstraction args): canvasinfo, pdinfo, objectinfo, classinfo
• ships with externals like Pd-extended did
• internal preset objects which work out-of-the-box with abstractions (preset_hub and preset_node)
• Bezier curve cords
• guaranteed pixel-exact box sizing across all platforms
• ability to create scalars inside object boxes
• grouping/affine transforms/images/sprites/opacity/standard-color-formats/standard-mouse-callbacks for data structure drawing commands
• working event callbacks for data structure array elements
• canvas array fields for data structures with "pointerless" field mutation (experimental)
• hyperlinked object errors in Pd Window
• cross-referenced help patches with hyperlinks
• complete list of arguments expansion with "$@" in both object and message boxes
• tooltips for iemgui dialogs
• click-draggable iemgui sizing
• click-draggable iemgui labels position
• click-draggable GOP canvases/canvas redrect/grid/scope~ sizing
• "Tidy Up" function which works well
• one-to-many/many-to-one/many-to-many wire-connections
• out-of-the-box [initbang] functionality
• "Put" menu array trace colors
• "Put" menu array bargraph style
• click-draggable "Put" menu graph sizing
• a fairly standard properties dialog for scalars
• throttling iemgui and scalar GUI updates
• ability to change ds array element drawings without having to redraw the entire scalar which contains that element
• single preferences panel
• ability to draw scalars in a box outside of which the contents are clipped
• simple testing framework to make sure all externals instantiate without crash or memory errors
• various fixes to externals that don't use aliases correctly
• various fixes to the loader
• find in console with results highlighted
• duplicate console messages get prefixed with number incremented in brackets
• fullscreen mode
• standard open/save dialogs under Gnu/Linux
• object z-ordering (move to front/back)
• standard keybindings inside editable object/message boxes and performant copy/pasting that doesn't freeze Pd with large amount of text
• lots of abstractions which are part of Ico's "K12" mode. I haven't ported the K12 interface yet but the abstractions are functional and handy.
• dropdown menu atom box
• ability to paste Pd source file into running instance

That's heavily biased toward what I've been working on lately which is improvements to scalars. But that should give you a decent idea. Also-- Purr Data doesn't include Deken, and Gem doesn't currently ship with the OSX version.

@th8a Thanks for the explanation. I wasn't aware of the drag-and-scale feature of gui objects in Purr Data. So unless there is some event message on scaling and a method to read the gop properties to adjust a subpatch containing the scalar, yes, the only method to get the scalars to scale would be to put them directly inside the main patch.

Still the reason for the crashes is that you have the scalar in the patch and then mess around with the struct object.

The way to prevent this is:

• Delete the scalar
• Create the object [struct $0-blinky float x float y]
• Add:
  [loadbang]
  |
  [scalar $0-blinky 0 0(
  |
  [s $0-blinky-cnv]

(Alternatively you can use the append method.)

This would mean that the scalar is created on load and also means that you would have to delete the scalar before saving the patch to avoid multiple scalars in the patch.

I would guess that with this you can get rid of all the delays as well.

If you can do without the drag-and-scale feature and be ok with just setting the size via creation argument or message, it is possible to do it the "clean" way with the scalar inside a subpatch.

@ingox yea... so the best I could do was get it to be stable when the scalar is in a subpatch, however this does not allow the graphic to be scaled by dragging the gop square on parent, which to me is the biggest advantage of svg graphics in the first place. If no scaling can be easily done, may as well use pixels... You have to open the subpatch to scale it, or send a donecanvasdialog message, and then if you save it. it will scale all instances of the abstraction. $0-naming of structs and scalars works if the structs and scalars are in a subpatch of the abstraction, however for some reason it won't work if the scalar is on the top level. The only way to name a scalar on the top level with a $0 prefix is to dynamically patch it at load time, but then ofcourse this crashes and makes it unstable. So, either i can make the button but it won't be scalable from the top level, or I make it but it crashes every time you call it in a text box. Ive spent many hours now trying to work around it... but every path I take seems to lead to some glitch or dead end... Im sorta ready just to table this and wait for updates of pd to hopefully fix the problem.... Here's what i got so far though. You can call one instance and it will work (sometimes) and you can copy and paste multiple instances and that works also. If you call it more than once from a textbox, it loads, you see the button flash once, and then crash. j-svbng-blu.pd

So I am starting to get a hold of how the whole thing works. I realized that some of what is there in the tutorial patch doesn't apply while using the [draw] object, which I believe is unique to purr-data... But no matter what I do, it seems like working with dynamically created structs causes a lot of instability. I modified my patch to create scalars in a subpatch with gop on so that i can clear the scalars and drawing instructions before creating new ones to avoid crashing. What i am finding is that the entire system gets unstable. PD will crash randomly or when creating send objects or objects with $0 prefixes, saved patches will open up with some of the object's missing or malformed, freezes, even an entire system crash at times, requiring full reboot. My patch was otherwise working well, but all of the scalars and pointers being tossed around just makes everything too unstable to even work, so I finally tabled the project until I can find a better way to do it, or some solution to the instability of structs (which I remember being a problem in various versions of PD,) are solidified to run without causing constant and consistent crashing and instability. Sorry for the news of failure... What might be really cool in the of purr-data future would be if the graphical instructions weren't bounded to the TK/Tcl constructs, and were handled independently by something more modern. Since purr uses the web-browser engine for it's UI, I envision something like an HTML wysiwyg editor to handle svg graphics and animations, like Adobe Edge or Tumult hype. Those programs let me know that HTML5 and JS in conjunction can be extremely powerful for graphics, animation and interactive interfaces. A full length animated movie could be made just in HTML5, potentially... Just my two cents and wishful thinking... but it would be cool....

This is a quick and fairly lightweight abstraction to get the mouse coordinates on click and drag motion. Three different modes determine the behavior for when the mouse leaves the click area. It works in Pure Data vanilla without any external.

Download: xy.zip

Usage:
Type [xy 500 300 1] to create a 500 x 300 pixel area in mode 1. See help file for details.

How it works:
A rectangle scalar of the size of the click area, a one pixel scalar and two graphical arrays are placed on top of each other. The second array has an inverted y-range. Both arrays are set to zero. On click both arrays jump to the respective y-value at x-position. When the rectangle scalar receives the click, it reads the x and y values from the first array. If y is zero, it takes the x value from the second array. Now we have x and y for the click.

The arrays are immediately reset to zero and the pixel scalar is placed to where the mouse is, so that it gets the grab. From there on x and y positions are read from the pixel scalar when its struct sends a change event. That's it.

Some more tricks where necessary to create everything dynamically and make it nice.

Have fun!

Update 2022-01-17: Finally fixed the bug that broke the patch when dragging near the bottom left corner. Everything should work now!

Hello there,

Could maybe someone explain the order of operations of my [sel] objects on both left and right. 1473000944963-1-working-2-not-working.pd Eventually, I want them to do the same thing, but 3 examples work very differently. (1) Works perfectly (2.1) and (2.2.) do not work in the same way as (1) does, although I am only omitting a few things, and without them I think it should still work in the same way.

I am new to PD, so I really want to understand everything that's going on, and I think that if I don't it will harm my future patching.