Each time a tabosc4~ reads a value from its table, it uses a combination of the four values closest to the given index. This allows it to produce a suitable value through interpolation even if the index isn't a whole number.

Let's imagine an object that does this without using guard values.

When the object is reading from the start of the table (any index less than 1), one of the four values it needs to combine lies before the start of the table. Because the waveform repeats, this is the same as the value at the end of the table. So the value can be read from there instead.

Similarly, when the object is reading from the end of the table (any index within 2 of the last index), one or two of the values it needs to combine lie beyond the end of the table. Because the waveform repeats, these are the same as the values at the start of the table. So the values can be read from there instead.

So our imaginary object without guard values works - what's the problem? The problem is that checking for those special cases increases the cost of looking up every value. It's more efficient to make copies of the extra values we need - one at the start and two at the end - when setting up the table. This extra work only needs to be done once, and then the lookup code that runs thousands of times per second can be as efficient as possible.

To answer the question about the discrepancy in the documentation about whether we should have three guard points at the end, or one at the start and two at the end: either way will work. Both approaches will produce waveforms that repeat cleanly, but the start point of the waveform (and thus its phase) will differ by one sample depending on which approach we choose. So if it's important to preserve the phase of your original waveform, add one guard point to the start and two to the end.

@jamcultur The command line flags set the devices to use when Pd is started. They can be used in Pd preferences to fix the devices without opening the midi dialog and saving the setup after starting Pd.
Not so useful in Pd preferences as they will always be the same, they are very useful if starting Pd from a batch file in windows, as you can have different setups for different hardware setups....... e.g. in the studio or out at a venue.
I am not sure how they could be used in Linux... maybe starting Pd from a shell script.

However, the order of devices almost definitely depends on the order in which they were plugged in before starting Pd so it needs some rigour to use -midioutdev. Using -midiaddindev and -midiaddoutdev rather than -midiindev and -midioutdev might solve that... ? I don't know the syntax..... but maybe a list of the devices by name and in the correct order after the flag...?
That could be problematic because of spaces in the device names.... see below.

I see elsewhere that you have a problem having to re-start Pd when plugging in more midi devices.
I wonder whether a request could be made to the Pd-list.
In Pd-extended devices were hot-connected when plugged in, but that is no longer the case in Vanilla. The midi-dialog.tcl file is completely different in the two versions and depends on other .tcl files and probably also on the Pd binary, so midi-dialog.tcl cannot be simply replaced.
There is also a fixed limit of 9 midi devices. I think windows has a limit of 10, and the registry needs to be edited by removing an old entry before adding a new one.

There are ways to set devices from within a patch using [midisettings]........ see set_midi-order.pd.... midisettings.zip
The idea is to reset the order of devices to what is required, by sending a list to Pd (a midi-dialog list).
It will need some work, using [midisettings] (part of the mediasettings external) as the names returned by the [listdevices( message are symbols with spaces inside. Since some version of vanilla the spaces can be escaped so the complete symbol can be used in the route object.... https://forum.pdpatchrepo.info/topic/13506/list-comparison/2
Otherwise, for older vanilla you will need [concat] which is in the thread.

So get the midi device names with their order numbers, and then re-order the numbers by device name according to what you require, and then send the re-ordered numbers back to Pd in a [midi-dialog( message.
When you implement that it will no longer matter in what order you plug the devices or in what order they appear in the midi settings menu when you start Pd.

Here is a quick re-write of set_midi-order.pd escaping spaces with a backslash for midi devices on my system....... set_midi-order.pd

The same can be achieved for audio devices using the [audio-dialog( message and [audiosettings].
David.

@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

@bellyband Hmm.....
I was going to suggest deleting the preferences in the registry (probably still at "Computer\HKEY_CURRENT_USER\Software\Pure-Data" ) but I see you have tried the -noprefs flag.
As it is starting wish it is getting part way through its startup sequence.

You don't need to start a patch as Pd starts...... out of the box you wouldn't have one to start.
Audio problems can stop Pd starting, even though dsp will not be running as it starts.

Create a shortcut to pd.exe in the bin folder. Edit the shortcut to open pd.exe with the -noprefs and -noaudio flags.... don't open a patch with the command.

If that doesn't work then try a portable version of Pd.
puredata/info seems to be down at the moment.
When it is back up go to this page ........ http://puredata.info/downloads/pd-extended ..... I remember that the page will allow you to navigate to recent versions of Pd vanilla.
Find a portable version of Pd for Windows...... it will be a .zip file that you can download and run anywhere (it does not require installation).
Unzip it into a folder on your desktop and double-click the Pd/bin/pd.exe binary.

If that doesn't work then try starting that binary with the -noprefs and -noaudio flags in a shortcut rather than a cmd window.

If that doesn't work then create a new user in windows, and see if that user can run Pd.
You could have a corrupted user profile in Windows 10.
And then, for the moment, I am out of ideas, but you could try uninstalling windows updates that have been installed since just before the problem first occurred.
David.

@Ossicone said:

What do I need to write in the receive box in the properties of my canvas in order to
change the colour of the label
change what the label says
change the colour of the canvas itself
all at the same time

Think of it like this.

The receive name is the name of the street.

The actions (change color, change label etc) are car brands traveling on the street.

Your question is, what should I name the street so that a Chevy and a Ford and a Porsche and a Tesla and a Toyota can all drive on the street?

And the answer of course is that the name of the street doesn't matter because all the cars can travel through it.

It's a non question. You don't need a separate Toyota street and a differently named Ford street. You just define one receive symbol -- one street. And you send all the cars -- all the messages -- through the one street. "color", "label" etc are messages. The receive symbol is a send/receive name. There is no correlation between them.

hjh

@cfry The simple hack to make this work on both in linux and OSX.
logger4.pd
Not completely sure the output of uname on OSX will be Darwin, if it does not work open up a terminal and run uname, what ever the output is is what you want to be the symbol in the [route]. And make sure to fix that path. You can also shorten that [del 1000], should be able to be dropped to at least 100.

The one fault with this is that killall tee is not great, it is possible there could be some other instance of tee running somewhere else and killall does kill all within the users permissions. OSX's paranoia might save you here, pd may not be able to kill apps which it did not start, depends on how they set things up. It is fairly safe as long as you do run pd as root and do not start any scripts running before sending that bang. Personally I would not worry about it until it bit me, I abuse killall to save having to get pids and it has only bitten me a few times in 20 years and never on something as innocuous as tee. If you are feeling paranoid or curious you can run tee in a terminal and then bang that right inlet to see if it kills the instance running in the terminal. We can make this safe with a few more [command]s if you want, need to rework a command like ps -f | grep "tee -a <log file name>" into playing well with [command], grab the pid and then run kill on that pid,

Thank you all.
@whale-av
@ben.wes
How would you implement the combinations formula (C (n, r) = n!/r! (n-r)!) in an efficient way? So that an n and r can be entered in and print all possible combinations?
I used the factorial expression object to calculate the combinations formula using- expr (fact($f1)) / ((fact($f2)) * (fact($f1 - $f2)))
What approach would you take to calculate the combinations formula without using the expressions object?
What approach would you take to calculate the combinations formula with using the expressions object?

Adding a List and or Array
How would you approach being able to add any type of customizable list/array (for example, list/array = A, B, C, D, E, F) and then telling the patch you want to generate any type of combination and then print all possible combinations?
For example, customizable list/array = A, B, C, D, E, F (n)
generate all possible combinations of 2 (r) also customizable
Print-
All possible combinations = 15
A, B
A, C
A, D
A, E
A, F
B, C
B, D
B, E
B, F
C, D
C, E
C, F
D, E
D, F
E, F

I am working on a piece that will turn on and off multiple motors at certain time based on certain variables.
What I'm trying to do is sequence like this:

sequence 1:
button is pressed

motor 1:
start at min 00: random pulse(ON time of 35 ms) every 7 - 10 sec
motor2:
start at min 01: random pulse(ON time of 35 ms) every 5 - 11 sec
motor3:
start at min 04: random pulse(ON time of 35 ms) every 3 - 13 sec
motor4:
start at min 06: random pulse(ON time of 35 ms) every 7 - 10 sec
motor5:
start at min 08: random pulse(ON time of 35 ms) every 5 - 12 sec
motor6:
start at min 10: random pulse(ON time of 35 ms) every 4 - 10 sec
all motors run

when button is pressed again (button count = 2):
sequence 2 starting:

motor 1:
continue random pulse(ON time of 35 ms) every 5 - 10 sec
stop after 01 min
motor 2: continue random pulse(ON time of 35 ms) every 3 - 12 sec
stop after 04 min
motor 3: continue random pulse(ON time of 35 ms) every 7 - 12 sec
stop after 10 min
motor 4: continue random pulse(ON time of 35 ms) every 3 - 8 sec
stop after 16 min
motor 5: continue random pulse(ON time of 35 ms) every 5 - 16 sec
stop after 18 min
motor 6: continue random pulse(ON time of 35 ms) every 7 - 10 sec

-- now only motor 6 is running >> button pressed>> last motor that running(motor 6) is stops.

sequence 3:

all motors pulsing together every 7 seconds for 2 minutes
after 2 minutes elapsed all motor stops.

how can I implements the above in PD?
how is possible to timing events without using metro rather something more accurate?

Thanks

@nicnut I was not really paying attention, so yes..... you found the problem yourself.....
The array is only written between a [start( and [stop( message.
The feedback control does nothing unless a new [start( message arrives, and if you don't press the overdub at exactly the start of the loop then the original recording loses the bit before you pressed it because it starts writing again from the first index of the array.
Same goes for the [stop( message..... but the bit after you stop is lost.
So I have tried to automate the start and stop of a single overdub. The toggle starts overdubbing at the start of the next loop, and stops at the end of a loop after you deselect it......... simple3.pd
Array removed as before.

Here is what I use live........ loop.zip
It's a bit simpler in reality to use a delay..... as you can feed in an overdub any time you like.
I use it for a specific piece.
The feedback is 100% for the piece, and it's score and tempo are determined...... except the length.
The number of patterns is set to exceed any possibility that the musician will get carried away.
The musician gives me a sign when he wants to end the piece and I hit the "cue seen" button. The patch then changes its click sound as it reaches the last bar, and auto-mutes the audio as the bar ends.
It doesn't use an array.... just a delay....
The OSC..... for my remote control from my phone...... needs updating for Vanilla as it uses MrPeach.
Levels are set during rehearsal.
I use it with ASIO in windows and a good soundcard.... otherwise latency upsets the artist.
I am sure that the final loop could be written to a file or an array afterwards if that is required.
David.

@seb-harmonik.ar said:

@alexandros in one case you're telling pd to start DSP
In the other pd is telling you that it has indeed been started

"telling pd to start DSP" = [s pd]

But here, the message is coming out of [r pd] -- so it isn't telling pd to start DSP. (Don't get confused by the "; pd dsp 1" -- to demonstrate the issue, it is of course necessary to start DSP. But the troublesome chain begins with an [r].)

@alexandros said:

So this:

[r pd]
|
[route dsp]
|
[sel 1]

gives different results than this?

[r pd-dsp-started]

I guess this should be fixed as well? Shouldn't it?

Not necessarily.

"dsp 1" / "dsp 0," as far as I can see, only reflect the state of the DSP switch.

The pd-dsp-started "bang" is sent not only when starting DSP, but also any time that the sample rate might have changed -- for example, creating or destroying a block~ object. That is, they correctly recognized that "dsp 1" isn't enough. If you have an abstraction that depends on the sample rate, and it has a [block~] where oversampling is controlled by an inlet, then it may be necessary to reinitialize when the oversampling factor changes.

It turns out that this is documented, quite well actually! I missed it at first because [samplerate~] seems like such a basic object, why would you need to check the help?

hjh