@yannseznec

@FFW said:

and since Pd v. 0.52 there is [file splitname]

@jumeca said:

I am working on building a patch that will work as an intermediary between an app built in C++ and a set of sound generators or puredata patches

Take a look in the helpfile of [file], - read/write binary files. and other things - maybe this is useful.

@ddw_music said:

I have seen Windows not adjust out of bounds window coordinates -- i.e., open a subpatch within a student's patch, and couldn't see the window at all.

... here is a patch that parses pd-patches and puts all windows back on screen:
move_windows_4ll.pd
test.pd

thx again!

(updated: should work now / now even loads whole directories of bigger projects with the new [file] object)

@fmiramar said:

seems that pd vanilla is eating the $...

this is because Vanilla reads $0 in objects only, not in messages.
PurrData does read [$0-arrayname(

you can substitute

[o]
|
[$0-arrayname(
|
[print}

by

[o]
|
[f $0]
|
[$1-arrayname(
[
[print]

https://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-messages/21

On topic of my first post:
Same happens with some [pd subpatches], too.

you can use [array random]

withArrayRandom.pd

Thank you

From time to time it happens with found patches around the Internet (quite annoying, but now I'm happy with the work-around). The window is minimized, small and blank.

I am not 100% sure if they all where made with Purr Data,
but am sure that at least some where made with it and someone told me once, her "Purr Data patches won't open in Vanilla",
so I assumed this would be a Purr Data > Vanilla thing, - could even be a cross-system problem or both or Win only. ...Didn't try to open with Purr Data or Linux...
They might also be made on higher resolution bigger screens or multi-screens.

51.4 and 52.1 Win10

Now I replaced the first line of these non-working patches by the working one:

#N canvas 80 229 1014 606 12; 

And yes they open now!

So these patches starting with

#N canvas 2802 562 675 300 12;

or

#N canvas 785 1198 794 777 12;

appear blank.

not sure why, but fixed

Why is that?

For example:

This helpfile of PDjs appears blank in Vanilla:
js-help.pd

#N canvas 2802 562 675 300 12;
#X obj 312 53 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 314 74 compile;
#X obj 240 253 print js;
#X text 412 204 Load JavaScript file js-help.js;
#X text 412 225 args are available through;
#X text 413 244 property jsarguments in JS;
#X obj 244 202 js js-help.js arg1 arg2;
#X text 371 73 recompile source;
#X text 11 9 js: Execute JavaScript;
#X floatatom 314 102 5 0 0 0 - - -;
#X msg 320 129 1 2 3;
#X text 331 51 call function bang;
#X text 357 99 call function msg_float;
#X text 373 129 call function list;
#X msg 142 61 setprop name test;
#X msg 143 87 getprop name;
#X text 25 59 set JS property;
#X text 26 88 get JS property;
#X msg 322 167 test x y z;
#X text 409 165 call function test;
#X text 41 28 https://github.com/mganss/pdjs;
#X connect 0 0 6 0;
#X connect 1 0 6 0;
#X connect 6 0 2 0;
#X connect 9 0 6 0;
#X connect 10 0 6 0;
#X connect 14 0 6 0;
#X connect 15 0 6 0;
#X connect 18 0 6 0;

That one is made in Vanilla and opens:
js-help-vanilla.pd

#N canvas 80 229 1014 606 12;
#X obj 142 191 js js-help.js arg1 arg2;
#X msg 127 59 setprop name test;
#X msg 127 85 getprop name;
#X obj 290 45 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 293 65 compile;
#X floatatom 293 93 5 0 0 0 - - -;
#X msg 304 118 1 2 3;
#X msg 308 149 test x y z;
#X obj 142 215 print js;
#X text 13 58 set JS property;
#X text 13 85 get JS property;
#X text 14 10 js: Execute JavaScript;
#X text 63 26 https://github.com/mganss/pdjs;
#X text 312 41 call function bang;
#X text 354 63 recompile source;
#X text 345 93 call function msg_float;
#X text 358 119 call function list;
#X text 394 149 call function test;
#X text 309 191 Load JavaScript file js-help.js;
#X text 309 212 args are available through;
#X text 309 234 property jsarguments in JS;
#X connect 0 0 8 0;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 3 0 0 0;
#X connect 4 0 0 0;
#X connect 5 0 0 0;
#X connect 6 0 0 0;
#X connect 7 0 0 0;

One more example:

A patch from the pd-list, does not open in Vanilla:
lock-in-amplifier.pd

@jancsika ?

... And Pd's Midi i/o and schedueling happens between the audioblocks of 64 samples only. You might have jitter at fast movements and low samplerates?

I think the fastest response you could get with standard Vanilla, is starting PD from the console with -noaudio -nosleep flags and maybe -nogui ... if you care about this.

uww

I updated my last post and think it is still valid.

But really, at a resolution of 16000 values on a fader length of maybe 10cm? This is almost a microphone! 20 years old ...
I wouldn't care too much about precision of the numbers. Take care to soothe any bigger jumps with the median-filter in realtime and you're done!?

@Bangflip said:

When I set my Fader in the DAW to 6 dBFS, my Conroller Fader moves correctly to 6 dBFS, as that is the highest fader value in Cubase. Also the other way around. If I set the Fader in Cubase to -00 dBFS, also my Fader of the controller is at the right position. So the lowest and highest values are correct. But if I set -20 dBFS in Cubase via Mackie UP Mode, my controller sets the fader to -10 dBFS. In the original Cubase "Steinberg Houston" mode, the fader movements are very precise and always are reflecting the number, which I set in the mixer in Cubase.

This is probably easy. I know consoles have some arbitrary? mapping.
You might easily match them with [pow]

nonlinearmap.pd