Obineg says: "and while GUI objects might be able to understand a message to set new min and max values, it is not good practice to use this feature to perform math operations"

I'd absolutely agree with this. Program logic should be program logic. GUIs should be for input or display. GUIs should not be performing program logic!

For that matter, sliders' min/max limits don't apply to values coming in:

The slider has set a limit max = 127. I sent in the number 150, and the slider sent out the number... 150. Not clipped to 127.

So you cannot use the GUI to enforce numeric limits at all. That is, the title of this thread is already leading in the wrong direction. A slider having a limit is irrelevant to what you're trying to do.

It seems like you're looking for an increment/decrement behavior that stops once it reaches a certain value (and then maybe triggers a different increment/decrement -- though this is unclear in your description because you say both "and change direction" and "once it hits the limit stays at that value until I press stop").

So, first, increment and decrement. You have the right idea with the float box. You don't need both a [+] and a [-] box because you can set the second operand: you can [+ 0.01] or [+ -0.01] using the same object.

Then, you need something that will decide whether the number is in range or out of range, i.e., you need numeric comparisons. I like [moses] for this but you could also use [>], [<] if you wanted.

So the way I would design "increment or decrement, and stop when the value goes out of range" might be like this.

Both buttons set the same initial value and start the metronome. The third outlet of the [t b b b] objects sets the up or down direction. Remember [t] outputs right to left, so the order is: 1/ set direction, 2/ set counter initial value, 3/ run the [metro].

At the top right is the "stop" signal (triggered by a too-low or too-high value). If you wanted to trigger some other action, you could put that here.

hjh

PS (edit) Actually the initializer could have slightly fewer crossing wires by splitting the [t] objects:

Hello,

in this patch there are three numerical lists that are merged into a single list, from which are extracted the values in a numeric box, one by one every second.
Everything works fine, except that the extraction of the singles values one by one ​​only works if I go to edit mode and I move slightly the "Three lists merged" list, then the extraction starts correctly. If I reset and merge the lists again, the problem returns.
Why?

list_01.pd

Thanks,

a.

I have the same problem...
You might use a french or german keyboard maybe?

The problem is that numeric keys are mapped to Command + Shift + digit key in such systems.
I finally ended by modifying some line of my pd_binding.tcl file long time ago to make them match my local keyboard.

For exemple (for french keyboard) for object box "CMD+1", I use "CMD + &":
bind all <$::modifier-ampersand> {menu_send_float %W obj 0}
For CMD+2, I use "CMD + é":
bind all <$::modifier-eacute> {menu_send_float %W msg 0}

This way I don't need to press 3 keys (CM + SHIFT + numeric) and only 2 keys like in us keyboard (CMD + &) and it removes the double box.
But I might be wrong?

Hello!

I'm attempting to use savestate to keep track of the number of cells and current value of a Vradio object in an abstraction to use a GUI element. A minimal example can be seen here:

Unfortunately, when using and then saving the abstraction, I get errors like

(Tcl) INVALID COMMAND NAME: invalid command name ".xb68310.c"
while executing
".xb68310.c delete bae6d0BASE0"
("uplevel" body line 13)
invoked from within
"uplevel #0 $docmds"

This seems beyond what i can decipher. Am i doing something very wrong in my abstraction or is this a bug?

Thanks

sbh

@whale-av huhh I installed cyclone and it works fine except for the help files. When I right click on a cyclone object and select "help" I get an error msg like this:

Tcl) INVALID COMMAND NAME: invalid command name ".x7084a0.c"
    while executing
".x7084a0.c delete bg3233770"
    ("uplevel" body line 180)
    invoked from within
"uplevel #0 $docmds"

I installed by using the find externals function, then added cyclone to load on startup. Am I missing some step to fully install it?

Thanks again @lacuna - great to have that thread as reference!

Just tried it for a bit: I cannot seem to find any binary releases in the github, https://github.com/mganss/pdjs (EDIT: found them https://github.com/mganss/pdjs/releases )- so I went along with this:

http://puredata.info/Members/mganss/software/pdjs/1.2.63/pdjs[v1.2.63](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Windows-amd64-32).dek/view

I don't really understand what this .dek file is supposed to be, but the page itself says it is a zip file, so I tried this (I use MSYS2 bash shell in Windows):

$ wget http://puredata.info/Members/mganss/software/pdjs/1.2.63/pdjs%5Bv1.2.63%5D%28Darwin-amd64-32%29%28Linux-amd64-32%29%28Linux-arm64-32%29%28Windows-amd64-32%29.dek/at_download/file -O pdjs_v1.2.63.dek

$ unzip pdjs_v1.2.63.dek
Archive:  pdjs_v1.2.63.dek
  inflating: pdjs/js.dll
  inflating: pdjs/js.l_arm64
  inflating: pdjs/js.pd_darwin
  inflating: pdjs/js-help.pd
  inflating: pdjs/js.pd_linux
  inflating: pdjs/js-help.js

nice, now I have a pdjs folder; so I tried copying it to my 32-bit copy of PurrData:

$ mv pdjs /c/bin/PurrData_x86_2.15.2/extra/
$ /c/bin/PurrData_x86_2.15.2/bin/pd.exe -verbose

Here, in an empty patch, I place an object [pdjs/js test.js] (see also the note in the Github README about declare -path pdjs); and I get:

...
tried C:\\Program Files (x86)\\Common Files\\Pd-l2ork\\pdjs\\js\\pdjs\\js.pd and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.m_i386 and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.dll and succeeded
verbose( 1):C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.dll: couldn't load
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.pd and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js.pat and failed
tried C:\\bin\\PurrData_x86_2.15.2\\extra\\pdjs\\js\\pdjs\\js.pd and failed
error: couldn't create "pdjs/js test.js"
...

Hmmm... library got found, but is not loaded; then I thought, let's check:

$ file /c/bin/PurrData_x86_2.15.2/bin/pd.exe
/c/bin/PurrData_x86_2.15.2/bin/pd.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows

$ file /c/bin/PurrData_x86_2.15.2/extra/pdjs/js.dll
/c/bin/PurrData_x86_2.15.2/extra/pdjs/js.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

Yeah - I cannot load a 64-bit .dll by a 32-bit .exe!

So, apparently, there is no 32-bit build for pdjs (see "Supported platforms" in the Github README), so I installed the 64-bit build of Purr Data ... and tried it there:

$ cp -a /c/bin/PurrData_x86_2.15.2/extra/pdjs /c/bin/PurrData_x86_64_2.15.2/extra/
$ /c/bin/PurrData_x86_64_2.15.2/bin/pd.exe -verbose

... and finally, could see it working - instantiating [pdjs/js test.js] gives messages:

...
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\pdjs\\js.m_i386 and failed
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\pdjs\\js.dll and succeeded
pdjs version 1.2.63 (v8 version 8.6.395.24)
tried C:\\bin\\PurrData_x86_2.15.2\\test.js and failed
tried C:\\Users\\user\\AppData\\Roaming\\Pd-l2ork\\test.js and failed
tried C:\\Program Files\\Common Files\\Pd-l2ork\\test.js and failed
tried C:\\bin\\PurrData_x86_64_2.15.2\\extra\\test.js and failed
error: Script file 'test.js' not found.
... click the link above to track it down, or click the 'Find Last Error' item in the Edit menu.
error: couldn't create "pdjs/js test.js"

One invocation that works for quick test is [pdjs/js pdjs/js-help.js], which succeeds - and then you can right-click the object and see the Help.

Finally, note this from the README:

There is no built-in editor like in Max, source files have to be created and edited outside of Pure Data.

Well, this is nice! On to see how to work with this object...

Thanks again for the help!

@yannseznec there is a limit in precision for any finite numerical representation. However, for floating point that becomes more complicated to calculate. The relevant code is

x->x_biginc = (x->x_target - x->x_value)/(t_float)nticks;
x->x_inc = x->x_1overn * x->x_biginc;

and in the dsp function:

x->x_1overn = 1./sp[0]->s_n;

so the inc will be (target value - current value)/(total time in samples). Time in samples will be rounded to the block size. I believe whether or not this number will increment the line~ depends on how big or small the current value of the line~ is. (again, it's complicated since it's floating point).
for instance if the current value of line~ is 1 then inc would have to be less than 2^-24 to not be able to increment I think. this would correspond to going from 1 to 2 over 16777216 samples, or ~6 minutes 20 seconds @ 44100 samplerate. (so you couldn't go from 1 to 2 any slower than that and have it represent the correct values within the block). Every time the value of line~ doubles so does the smallest representable increment.
however, line~ also uses the biginc variable, which means that after every block it will be able to update using a bigger increment. This means that line~ will still be able to increment up to blocksize times more than that calculation ^ after every block, though values inside every block would be the same. (so ~6 hours 46 minutes @ blocksize 64 according the above calculation I think)

if going from 0 to 1 all of those values would be doubled (it could represent increments corresponding to twice that time, bounded by the lowest representable increment that corresponds to going from 0.5 to 1)

there are other considerations of precision as well. If the increment can only be represented with a certain number of binary digits when added to the current value then there will be round-off errors in the values generated. (but if you need values of that precision you would have round-off errors somewhere else anyways probably)

another numerical bound on the use of line~ is the use of an int to represent ticksleft. If we assume this is a 32-bit signed integer then there can only be 2,147,483,647 blocks, which is ~36 days @ 44100 samplerate and a blocksize of 64. (this would be longer than whatever limitation the floating-point would impose tho I think)

this is all assuming that the size pd uses for samples and floats are 32-bit floating point. If pd is compiled to use 64-bit doubles instead then all of those values would be 2^29 times longer

edit: actually, looking at the code vline~ does use doubles for everything, so if you need really long ramps you should have no problem if you use vline~ instead of line~, even in normal non-double pd. It would take a time longer than 6,472 years for a vline~ going from 1 to 2 to stop being able to increment within a block of 64 samples @ 44.1k. (and a time of 414216 years to stop incrementing at all across blocks)
In the case of vline~ the bounding factor of precision might be in the representation of time actually since it doesn't use ticksleft
edit 2: it couldn't represent incrementing ~1.45 ms which is the time for a block of 64 @ 44100 samples if the current time were ~ 2^53 ms, which would be 9007199254740992, or 285,421 years before stopping to work completely.

long story short: you should be able to use vline~ (but not line~) for ramps of at least a few years long (depending on the range of its values) before it stops incrementing within a block. For the specific case of going from 0 to 1 @ 44.1k, you should be able to run a vline~ for ~129,000 years before it stops incrementing within a block (though it would still increment between blocks)

I get this error message. Everything seems to work. But what does it mean? Should I fix it?

Thanks!

(Tcl) INVALID COMMAND NAME: invalid command name ".x100235de0.c"
    while executing
"$tkcanvas itemconfig $tag -text [::pdtk_text::unescape $text]"
    (procedure "pdtk_text_set" line 2)
    invoked from within
"pdtk_text_set .x100235de0.c .x100235de0.t1003abd40 {-5.08 }"
    ("uplevel" body line 4)
    invoked from within
"uplevel #0 $docmds"

@ddw_music said:

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block. (There might be a way to use [random] in this case too, but I'm on my phone and won't work it out just now.)

When the random number is triggered by a control message, then [random] will absolutely be more efficient (by being idle while "holding").

hjh

Just for reference:

Proves that this what actually my situation (I guess).

I started to get this message:

(Tcl) INVALID COMMAND NAME: invalid command name ".x1072d5860.c"
    while executing
"$tkcanvas itemconfig $tag -text [::pdtk_text::unescape $text]"
    (procedure "pdtk_text_set" line 2)
    invoked from within
"pdtk_text_set .x1072d5860.c .x1072d5860.t10037fcc0 {-4.16 }"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $docmds"

Once I removed my random sample and hold the message stopped occuring.

I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

Could that error message be due to mismatched control/audio domain?

thats interesting, i can reproduce the error, but only if the parent patch is not saved (does not have a name).

(Tcl) INVALID COMMAND NAME: invalid command name ".x6bd840.c"
    while executing
".x6bd840.c delete 703420IN0"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 $docmds"

with a [send] object it works without a placeholder name.