-
lacuna
@jameslo For me it is difficult to understand. Maybe I am missing the whole point and all I say is off topic.
First of all, I honestly don't understand why your left bang works
click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).
Similarly, in my first response to you, you can see in the snapshots that the bang from [delay 1.5 64 samp] is being processed during Ctrl 1, 32 samples before its real timing.
This I don't understand.
You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries. (That's why there is [vsnapshot~], but that was buggy, when I last tried it.) [snapshot~] shows 64 samples, one whole block.
If you snapshot later, you see [del 1.5 64] outputs bang after 96 samples:
([sig~] also updates its output only on block-boundaries, not within the block.)@seb-harmonik-ar s [pip~] could be done with [bang~] and [timer], to measure the time that has passed into the block.
Or for signalrate~ output~ with [rpole~ 1], to measure the samples past into the block.you don't need to predict the future to make it one block earlier
So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block? To the start of that block where [del] outputs later on a message to [vline~]?
Clicking [o] bang at ctrl 0 > [del 1] outputs after 1 ms, where audio 0 is happening > [vline~] should have started before, at the beginning of audio 0 ?
Is this what you want?
Here is a paper where message- vs signal-domain and scheduleing are graphed. It is in German, maybe you can use a translator and the time-graphs on the last pages are english / self-explanatory. And you problably already know all of this.
https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view -
lacuna
@jameslo Thought that's what you where looking for? 'block-quatizer'?
But you want to move the output of [del 1] back to the start of the block?
Interesting, but I think moving backward is not possible in realtime Pd ... (hmmm there is the [lrshift~] object for moving in a block... )Edit: My point was that this quantizes to (next) block boundary, and if already at it, it stays there.
[del 0] Breaks the deterministic order ( [t b b] ect.), as [delay] and [pipe] always do, and moves to the last point after everything else deterministic is processed, but keeps at the same logical time (zero delay).
But what was your point?
Edit: Now I tried without [del 0] and everything is the same. So I completely missed your point?? -
lacuna
@jameslo said:
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".
Man, this got me excited because the only reason my bang quantizer outputs where it does and not one block earlier is because [bang~] for the end of the first block has already executed by the time my spigot opens and so we have to wait for the next audio block to complete. I was hoping [delay 0] would cause the bang from [bang~] to be rescheduled after my spigot opens, but it doesn't appear to.
That works, screenshot when left bang is clicked:
vline~blockquantizer.pd(thought [bang~] would be expensive, that's why I [switch~]ed it in the other patch.)
-
lacuna
@jameslo said:
Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?
Like this?
vline~onnextblockboundary.pd
Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]
As far as I understand it now, some objects
([metro] [del] [pipe] [vline~] maybe[vsnapshot~])
do intra-block-messaging/banging and some won't (like [tabwrite~] in my patch).The scheduler processes GUI and Midi i/o at block-boundaries.
I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.
-
lacuna
since Pd-list got an update in August 2024 it has moved? and links are broken. Not a big issue, as we can sill find it lists.iem.at
-
lacuna
Also IEM has list of Vanilla objects page online:
https://pd.iem.sh/objects/ -
lacuna
@porres the "garbage-filter" since 0,49, as it won't show abstractions w/o helpfile. And the hiccup.
@SCFan32 My recommendation for learning Pd is keeping it straight Vanilla and go the way @whale-av proposed: Learn the list of objects Vanilla vocabulary and learn thinking in Vanilla, instead of searching for objects. This would be the low-level Pd-Vanilla way.
From what I have glimpsed SC is not so very low-low level.
Searching objects of libraries can be done in Deken. Help > Find externals
or deken.puredata.info where ctrl+f full text search helps, too.There are some libraries that make easy high-level patching possible. But the bigger they are, and the more libs you use, the more you have to search for objects.
Searching this forum: https://forum.pdpatchrepo.info/topic/11732/commands-for-forum-search-engine/2
Where in many cases newer posts are more valid, because Pd-Vanilla has developed a lot and solved many issues, added more objects ect.
(keeping backward-compability). -
lacuna
Mabye
[symbol]
|
[float]does the trick?
Pobably it is not encoded as float but neither has no symbol selector.
A symbol without 'symbol' selector looks like a float but isn't.(btw there is [int] but ints are floats in pd)
-
lacuna
I currently don't have Else lib installed, so no definetive answer, also I don't know those Else objects and did not look into their help-files ... only answering because noone did (EDIT well now I'm late), but looking at your patch:
- [print] helps debugging such things!
- After [list prepend amp] you might need [list trim] to remove the 'list' selector from the message (check with [print]).
- Cut the connection between [multi.vsl] and [bpbank~] !? Or why are they connected?
- Vanilla-ways to build such a message as [amp 0 2 0 2 ( would be:
-
lacuna
@dmanz sorry, I was wrong in a rush and corrected my last post now:
[t b a] not [t a b]
it is right to left order,
first set the message (anything) then bang.