@cfry said:

The problem that arise is that when I start to improvise I kind of "break the (your) concept". And I would like to avoid ending up in another patch that is so messy that I can not use it if I bring it up after a half a year or so. Lets continue working on it!

You are definitely getting parts of it and seeing how to develop it but there are parts you don't quite have yet and I can't quite identify what those are so I can explain things. I made a sizable patch that adds a lot of commands but last night I realized I went to far and it would probably confuse things for you, so I will reduce it down to just the things you mentioned, I will follow your lead.

Passing the text name as an argument is just a matter of using your dollar arguments, [text get $1], but you will want to tweak your input for text symbols some.

So our right inlet for text symbols goes to a send now so we can easily access that text anywhere in the patch, like in our commands, and we also reset the counter which uses a value for its float for the same reason, we will want to be able to access and change its value from commands. "pc" is short for program counter and it is important that we increment its value before sending a float to the text get otherwise if we change its value in some command it will get overwritten, so having a [t f f] here is almost a must. This also means that [v $0pc] points to the next line to be run and not the one that is currently being run, this is important, fairly useful, and occasionally irksome.

The left inlet has change some as well, we have a [route bang float], bangs and floats go to the counter so we can increment the program or set the next line to be run, the right outlet sends to our [list-drip] which enables us to run commands from the parent patch so when things don't work you can run that print command to print the stack and get some insight or just run commands from a listbox to test things out or whatnot. We also have [r $0bang] on the counter, this lets us increment the counter immediately from a command and start the next line. And finally we have a new outlet that bangs when we reach the end of the text file so we can turn off the metro in the parent patch which is doing the banging, reset the counter to zero, load a new program, or what ever you want to do when the program completes. Middle outlet I did away with, globals can be done as a command, as can most everything.

Variables we can implement with some dynamic patching and a simple abstraction to create the commands for setting and getting the value of any variable.

This looks more complicated than it is. If we have the line var val1 10 in our program it runs the var command which bangs [v $0pc] and subtracts 1 from it to get the current line from the text holding our program and then appends our $0 to it giving us the list var val1 10 $0. The first message it goes to creates an instance of the var.pd abstraction in [pd $0var] with the second and fourth elements of the list as arguments, val1 and $0. Second message sends $3 to $4->$2, 10 to $0->val1. To finish off we use that new $0bang receive to bang [v $0pc] so we don't execute the rest of the line which would run val1 pushing 10 to the stack and then push another 10 to the stack. Variable name with a > prepended to it is the command for setting the value of a variable, 22 >val1 in your program would set the value of val1 to 22, val1 would push 22 to the stack. If we could see how pd expands all those dollar arguments in the abstraction it would look like this:

Now you can create as many variables as you would like in your programs and a couple tweaks you can have the abstraction global.pd and subpatch [pd $0globals] so you can have the line global val2 0 and get a global variable that all instances of tracky can read and write from. There are a couple catches, each variable definition must appear on its own line with nothing else after it and with our simple parsing there is nothing to stop you from creating multiple instances of the same variable, if you run the line var val1 10 a second time it will create a second abstraction so when you run val1 it will bang both and each will push 10 to the stack giving you an extra 10 and screw up your program. We can fix this with adding a registry to the var command which searches a [text] to see if it has been created already, something like this after the [list $0] should do it:

And you will want to create a command to clear all variables (and the text if you use it) by sending [clear( to [pd-$0var], or get fancy and add another command in var.pd which bangs [iemguts/canvasdelete] so you can delete individual variables. Using [canvasdelete] has the advantage of not needing a registry for variables, you can just always run ```delete-<variable name>, or what ever you name your delete command, before creating a new variable. Each method has advantages.

Your loop does not work because the unpack needs to go into the left inlet of the float, that triggers the first loop and causes it to go back, each time the program gets back up to the loop command it increments [v $0loopi] until the select hits the target number of loops which sets $0loopi to -1 which ends the looping.

Not sure what you mean by groups/exclusive groups, can you elaborate or show it with a patch?

None of the above has been tested, but I did think them through better than I did the loop, fairly certain all is well but there might be a bug or two for you to find. Letting you patch them since we think about how things work more when we patch than when we use a patch. Try and sort out and how they work from the pictures and then patch them together without the pictures, following your understanding of them instead of your memory of how I did it. And change them as needed to suit your needs.

@lacuna said:

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Yes, this is how I was hoping it would work, but it's not always the case that [bang~] bangs after the spigot is open within the same control block. It appears to bang afterward if there is a direct bang from a GUI element, but bangs before if the bang came from a delay. (Edit: I'm going to start a new topic on this, I don't see why this should be true)
bang~ runs last.pd
bang~ runs first.pd
If it runs before, then we are really waiting until it bangs at the end of the next audio block. (BTW, you can modify the number of blocks of delay and see the numbers change as you'd expect)

You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries.

Yes, but all I'm concluding from that is that the message is available in the control block before the audio block that contains its actual time. The fact that so many Pd objects ignore the fractional block of time remaining suggests to me that it could be possible to truncate that fractional block of time in the message in order to make objects like vline~ start at the beginning of the audio block, like sig~.

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block?

Your diagram annotation is correct, but "want" is a strong word . Let's just say I'm curious if it's possible. Right now, I'm delaying things like [sig~] to match [vline~] by inserting [vline~] just before them. I could have used any of our 3 quantizers to align the first [vline~] ramp with the block following the block that contains the fractional block timed message, but then I would have had to also delay my [sig~] processing a block as @seb-harmonik-ar confirmed.

The last two slides in that PP deck you linked to shows what I mean. Objects like [vline~] implement the ideal, but I'm wondering how to make it behave more like the last slide. See how the message's timing is labeled "t0+16"? Wouldn't it be possible just to zero out the "16" part?

@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,

@esaruoho wrote:

16 "LFOs" to "breathe" up and down the volume slider

How does your modulation LFO look like?
Is the modulator a signal or control-object?
Does it offset or master the fader ?

Did you try what I mentioned in your other thread?
https://forum.pdpatchrepo.info/topic/14291/need-a-simpler-way-to-change-slider-background-color-when-on-and-off/6

If you update the GUI on each block
= SR/64 = 44100 /64=689 times per second,
this is overkill and is going to drag down performance, even if the two parts run asynchronously.
<25 frames per second should be enough for the GUI.

Setting many faders and their colour once in a while should not cause any trouble. Limiting the update rate might be enough to run stable. (see the patch below)

Benefit from separating GUI- and audio-parts across two PD-instances would be, if the GUI is lagging, audio still runs without drop-outs as PD-instances run asynchronous.

Ideally run the PD-instances on different CPU-cores (and audio in higher priority) by setting this in the operating system.

(btw offtopic, to complicate things even further: in case you are not aware of it:
there is also the [pd~] object, which does simple multithreading, splitting patches across the CPU-cores. But the parts are running synchronous.
Running one instance of Pure Data only, without [pd~], everything runs on one core only.)

For real-time audio a synchronous chain between input and output is important.
So no, unless you know what you are doing, don't split audio into several PD-instances.
(but yes, on different cores with [pd~], in case the audio-part runs out of CPU-time and you don't want to increase latency).

Sth like this is what I thought about in the other thread, slowing down GUI-update-rate with [metro] and [snapshot~]
and detaching it from the deterministic chain with [pipe],
while maintaining signal-rate amplitude modulation:

fader-abstraction.pd
slider-guts.pd

(I don't have Vanilla here right now, and doesn't work on web-PurrData,. But should work on Vanilla, if there is no bug!?)
EDIT: changed [pipe 5] and added [change] and set fader properties to "jump on click"

I'm not sure how many of these comments are addressed to me or the other David, but in any case, I'm getting a little confused. To get back to my original post (and ignoring the issue of guard points, which I know is important but not really relevant to my question), I'd like to reiterate:

1. I didn't use Audacity to record anything, I just used it to create a sound file with one of the built-in UGEN's (create a new track, then click on 'Generate->Pluck...' in the toolbar). Really, the file could have originated anywhere, and whether or not there were timing inaccuracies when it was created is completely irrelevant. I'm just comparing the way it sounds when played back in Audacity vs. when it's played back in my Pure Data patch.

2. Someone asked me "how much is it off by"; I'm not sure how to answer that, except to say that it sounds about one semi-tone higher in Audacity than it does in Pure Data, although I don't have a very good ear for pitch. (If the problem was in Audacity, wouldn't the frequency be lower in Audacity than in Pure Data or is that an over-simplification?)

3. I don't think I mentioned this, but I'm running both on the same computer, a HP-P6230F (with a quad-core processor running at 2.60 GHz running Windows 10 64-bit). I was going to provide a link to the specs on the HP web site, but they seem to have removed the page (it's an old computer). I'm running Pure Data 0.53.2, 64-bit, and Audacity 3.2.5, 64-bit.

4. Also not previously mentioned, I tried running Pd in both real-time and non-real-time mode, but it didn't seem to make any difference.

I appreciate everyone's help, but can we limit the discussion to my original question and ignore other issues like guard points, interpolation (which I don't think applies to my question, since I'm playing the file back at the original speed) and problems related to recording in Audacity? They probably deserve a thread of their own, anyway.

I wanted to build PD on Windows 10 to get ASIO support. I failed when I used the "Source" files from the PD website. I succeeded when I used source that I cloned from Github. I followed the same instructions from the wiki both when I failed and when I succeeded. (They are the same as in the manual, just a little more concise.)

I am sharing below my terminal output from the failed build attempts from the downloaded source code (the tar.gz file). Some of these messages suggest that there might be errors in the makefiles. I don't know anything about makefiles, so I can't really interpret the errors. But I did want to pass them along, in case a developer might find them useful. Here you go:

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./autogen.sh
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'm4/config'.
libtoolize: linking file 'm4/config/config.guess'
libtoolize: linking file 'm4/config/config.sub'
libtoolize: linking file 'm4/config/install-sh'
libtoolize: linking file 'm4/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/generated'.
libtoolize: linking file 'm4/generated/libtool.m4'
libtoolize: linking file 'm4/generated/ltoptions.m4'
libtoolize: linking file 'm4/generated/ltsugar.m4'
libtoolize: linking file 'm4/generated/ltversion.m4'
libtoolize: linking file 'm4/generated/lt~obsolete.m4'
configure.ac:166: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
configure.ac:166: You should run autoupdate.
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:166: warning: AC_LIBTOOL_DLOPEN: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:166: put the 'dlopen' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:167: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
configure.ac:167: You should run autoupdate.
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:167: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:167: put the 'win32-dll' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:168: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:168: You should run autoupdate.
aclocal.m4:121: AC_PROG_LIBTOOL is expanded from...
configure.ac:168: the top level
configure.ac:182: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:182: You should run autoupdate.
../autoconf-2.71/lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:182: the top level
configure.ac:213: warning: The macro `AC_TYPE_SIGNAL' is obsolete.
configure.ac:213: You should run autoupdate.
../autoconf-2.71/lib/autoconf/types.m4:776: AC_TYPE_SIGNAL is expanded from...
configure.ac:213: the top level
configure.ac:235: warning: The macro `AC_CHECK_LIBM' is obsolete.
configure.ac:235: You should run autoupdate.
aclocal.m4:3879: AC_CHECK_LIBM is expanded from...
configure.ac:235: the top level
configure.ac:276: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:276: You should run autoupdate.
../autoconf-2.71/lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
m4/universal.m4:14: PD_CHECK_UNIVERSAL is expanded from...
configure.ac:276: the top level
configure.ac:168: installing 'm4/config/compile'
configure.ac:9: installing 'm4/config/missing'
asio/Makefile.am: installing 'm4/config/depcomp'

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ autoupdate
configure.ac:182: warning: The preprocessor macro `STDC_HEADERS' is obsolete.
  Except in unusual embedded environments, you can safely include all
  ISO C90 headers unconditionally.
configure.ac:213: warning: your code may safely assume C89 semantics that RETSIGTYPE is void.
Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ^C

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./configure
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests
configure: Android SDK only available for arm-linux hosts, skipping tests
checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw64/bin/nm -B
checking the name lister (/mingw64/bin/nm -B) interface... BSD nm
checking whether ln -s works... no, using cp -pR
checking the maximum length of command line arguments... 8192
checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32
checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... (cached) objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... (cached) dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw64/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for vfork.h... no
checking for dlfcn.h... no
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether make sets $(MAKE)... (cached) yes
checking whether ln -s works... no, using cp -pR
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for windres... windres
checking for egrep... (cached) /usr/bin/grep -E
checking for fcntl.h... yes
checking for limits.h... yes
checking for malloc.h... yes
checking for netdb.h... no
checking for netinet/in.h... no
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/ioctl.h... no
checking for sys/param.h... yes
checking for sys/socket.h... no
checking for sys/soundcard.h... no
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for unistd.h... (cached) yes
checking for int16_t... yes
checking for int32_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for working alloca.h... no
checking for alloca... yes
checking for error_at_line... no
checking for fork... no
checking for vfork... no
checking for GNU libc compatible malloc... (cached) yes
checking for GNU libc compatible realloc... (cached) yes
checking return type of signal handlers... void
checking for dup2... yes
checking for floor... yes
checking for getcwd... yes
checking for gethostbyname... no
checking for gettimeofday... yes
checking for memmove... yes
checking for memset... yes
checking for pow... yes
checking for regcomp... no
checking for select... no
checking for socket... no
checking for sqrt... yes
checking for strchr... yes
checking for strerror... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for dlopen in -ldl... no
checking for cos in -lm... yes
checking for CoreAudio/CoreAudio.h... no
checking for pthread_create in -lpthread... yes
checking for msgfmt... yes
checking for sys/soundcard.h... (cached) no
checking for snd_pcm_info in -lasound... no
configure: Using included PortAudio
configure: Using included PortMidi
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating asio/Makefile
config.status: creating doc/Makefile
config.status: creating font/Makefile
config.status: creating mac/Makefile
config.status: creating man/Makefile
config.status: creating msw/Makefile
config.status: creating portaudio/Makefile
config.status: creating portmidi/Makefile
config.status: creating tcl/Makefile
config.status: creating tcl/pd-gui
config.status: creating po/Makefile
config.status: creating src/Makefile
config.status: creating extra/Makefile
config.status: creating extra/bob~/GNUmakefile
config.status: creating extra/bonk~/GNUmakefile
config.status: creating extra/choice/GNUmakefile
config.status: creating extra/fiddle~/GNUmakefile
config.status: creating extra/loop~/GNUmakefile
config.status: creating extra/lrshift~/GNUmakefile
config.status: creating extra/pd~/GNUmakefile
config.status: creating extra/pique/GNUmakefile
config.status: creating extra/sigmund~/GNUmakefile
config.status: creating extra/stdout/GNUmakefile
config.status: creating pd.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure:

    pd 0.51.4 is now configured

    Platform:             MinGW
    Debug build:          no
    Universal build:      no
    Localizations:        yes
    Source directory:     .
    Installation prefix:  /mingw64

    Compiler:             gcc
    CPPFLAGS:
    CFLAGS:               -g -O2 -ffast-math -funroll-loops -fomit-frame-pointer -O3
    LDFLAGS:
    INCLUDES:
    LIBS:                 -lpthread

    External extension:   dll
    External CFLAGS:      -mms-bitfields
    External LDFLAGS:     -s -Wl,--enable-auto-import -no-undefined -lpd

    fftw:                 no
    wish(tcl/tk):         wish85.exe
    audio APIs:           PortAudio ASIO MMIO
    midi APIs:            PortMidi


bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Useras/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make app
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Users/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1

It's hard to tell without knowing your setup. OS? Hardware?

I run PD vanilla on xubuntu 20.?? (latest LTS) and an external sound card/mixer (cheap behringer). I can get audio both with and without jack

If I set up PD to run just with ALSA (no jack) and I have some other programs running that are using the sound card (like a browser or whatever) PD will tell me:

ALSA input error (snd_pcm_open): No such file or directory
ALSA output error (snd_pcm_open): No such file or directory

However, closing my browser and/or other programs that route sound through ALSA solves this

Using jack instead gives me the advantage of running other DAW software along side PD and route both midi and audio back and forth between them (non jack programs will be silenced), but jack has to be set up properly for the server to run without dropouts (select the correct soundcard, buffer size etc in settings), or even start at all. For this purpose I use qjackctl, which is a GUI control panel for the jack server- should be in your distro's repositories.

The errors you get with jack simply states that the jack server is not running- it has to be started manually. You can do that with a command from your terminal or get the qjackctl software for the GUI (which I reckon you will prefer as a windows convert). Run: sudo apt install qjackctl from your terminal to install it if you are using a debian based distro (*ubuntu, mint et al)

@60hz said:

So what I see is that pd-vanilla and his minimal gui with computer scientists oriented documentation is not suited for newcomers and artist but purr-data is. So that should make sense that flossmanuals should have a documentation about it.

It makes sense and we're saying Purr Data can have its own Floss manuals, but what are you talking about, a new entry or turning the current Floss Manuals into a Purr Data Manual?

By the way, the point of updating this Floss manuals to Vanilla is to make its documentation and itself more suited for newcomers, the solution to the exact problem you're raising it won't change if we don't do anything about it and if efforts to change it are rejected.

Folks, when I started this thread, I made no mention to Purr Data. Purr Data is something else. I get the confusion, I get the relation, it's not out of purpose to bring this up here, but I want to make things clear.

See, we're talking about a Manual, a so called "Pure Data" manual, which actually mixed the notion of Pd itself and Pd Extended (now dead) and sits around still as a "Pure Data" manual. While Pd itself has also its 'official' manual. That's all very confusing already, right? The point is then to fix this, work on the Pure Data documentation itself (it's all in the original post). Purr Data relates to Pd and Extended but it's a whole different animal. It has different configurations, interface, features and whatnot. More over, it has quite strong incompatibilities that people don't seem to bring up. When you have a so called Pure Data manual talking now about 'Purr Data' actually, things get even more confusing, we're adding more noise.

What's also confusing is the mixed notion of a 'Software Manual' and a 'Tutorial'. These are supposed to be distinct things. And tutorials are free to focus on different things. Floss seems to be a tutorial on how to do some stuff in Pd, not a 'real software manual' at all. Floss also seems to be good to talk about some externals for Pd. Cool... we could update it then and keep it mostly the same. The changes would be minimal. We'd have a good section on how to manage externals in Pd Vanilla theses days. That'd be great, right? How to configure, etc...

If you're saying, "but hey, I think most of the tutorial examples would work on Purr Data, as they already ship the externals we're talking about, cause they were originally based in Extended", fine! Cool! Great, we can see if what we have in the end perfectly suits being just implemented, opened, and used in Purr Data as well. I'm not talking about the configuration part and things like that, just running the patches...

If it's all fine we can just say "hey, the things you see here are also suited if you want to run Purr Data"

How about it?

Note: On the other side, I prefer using pd-ceammc libraries which are organized AND replace all pd-extended and more, so the best would be having Purr Data + ceammc lib and the peace would come back on earth...

They do not, by far, replace "all pd-extended", nope, sorry, not a fact. Where's ceammc's GEM replacement for instance?

And what are you suggesting with "Purr Data + ceammc lib"? A Floss manuals for both?

And are you talking about the ceammc library that you can install directly from vanilla and use it as part of vanilla or the 'Pd-ceammc' fork of Pd, that comes with the ceammc library and some more stuff?

Well... everything I said about "hey what about Purr Data?" applies here. And the fact is that Pd-ceammc, unlike Purr Data, is not a "whole different animal", it's pretty much just another 'race' of Pd. It is 100% compatible to Pd-Vanilla (unlike Purr Data). the changes are minimal. You can, for example, run Deken and install externals in Pd-ceammc.

If you don't want to bother using something else than Vanilla, you can install the ceammc library in Vanilla and just use most of what ceammc offers anyway. It's all compatible.

So any Pure Data Manual, Floss manual, tutorial, will work great for Pd-ceammc. And if we consider the fact that a Manual for Purr is needed (not a tutorial, a 'manual', a 'software manual') since it's just too different. That doesn't hold for Pd-ceammc.

And yeah, when I say Purr Data is highly incompatible, you can't run any of the GUI objects from Pd-ceammc in Purr Data. You can't run other GUIs from other libraries.

In fact, Purr Data doesn't even have all of the GUI externals from extended ported and running. Also, Purr Data misses updates from cyclone. Purr is also not doing a great job keeping up to the latest vanilla changes and has some changes of their own to vanilla things. So, unlike Extended and Vanilla, it's really hard tying them with a knot. Unfortunately, at least to me, the community is divided. There are independent developments. And it's hard to manage this, hence the talk about creating a whole new FLOSS for them if needed.

If Purr Data were in fact a reincarnation of Extended, fine. But that's not quite it. And here's something people don't really seem to be aware is that the best shot to have an updated external library that runs all extended patches is going to be "Vanilla + install externals yourself"

And there's also the fact that there are more libraries than just the extended libraries out there, and you can also get them into Vanilla. Like ceammc, like timbreid, like soundhack, like ELSE, like many many others that are just missing, not compatible or hard to get into Purr.

So, there's a way to have both Pd-ceamm + Purr Data when it comes to the externals - get them all for vanilla!

Sure, you'll miss the interface differences from Purr and maybe I don't know what. But that's it, and it needs to be clear what the choice is, there's also a sacrifice in giving up Vanilla.

Hi,
with Firefox 88.0.1, Ubuntu 21.04 it loads and then Exception thrown, see JavaScript console:

unreachable code after return statement
EmscriptenExample.js:8289:4
unreachable code after return statement
EmscriptenExample.js:8413:4
undefined gameoflife.handmadeproductions.de:41:33
    printErr https://gameoflife.handmadeproductions.de/:41
    abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:859
    _abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:124923
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:6889037
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:6889238
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:858086
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:766433
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:1044857
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:1488944
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:795390
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:193441
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:2719626
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:3663705
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:2876770
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:4943251
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:4467908
    _main https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    (Asynchrone : setTimeout handler)
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
exception thrown: RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.,abort@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:863:13
_abort@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284:5
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[497]:0x1e7fb
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[12138]:0x691e4d
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[12139]:0x691f16
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[2153]:0xd17e6
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[1931]:0xbb1e1
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[2449]:0xff179
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[3427]:0x16b830
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[1989]:0xc22fe
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[655]:0x2f3a1
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[6070]:0x297f8a
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[9295]:0x37e759
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[6933]:0x2be562
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[10347]:0x4b6d93
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[9921]:0x442cc4
Module._main@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697:60
callMain@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601:32
doRun@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641:21
run/<@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650:13
setTimeout handler*run@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646:19
runCaller@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591:9
removeRunDependency@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848:13
receiveInstance@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920:28
receiveInstantiatedSource@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924:24
promise callback*instantiateAsync/<@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940:31
promise callback*instantiateAsync@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938:16
createWasm@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959:5
@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687:11
gameoflife.handmadeproductions.de:41:33
    printErr https://gameoflife.handmadeproductions.de/:41
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10614
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    (Asynchrone : setTimeout handler)
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
Uncaught RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.
    abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:863
    _abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284
    _main https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    setTimeout handler*run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    promise callback*instantiateAsync/< https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    promise callback*instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonymous> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
EmscriptenExample.js:863:13

​

Hello folks,

I have been struggling for the last several days trying to get any version of Puredata to work correctly on Chromebook Crostini. It almost works. It runs and I get sound but it is extremely scratchy and broken up.

Firstly, I know that audio can work because csound 6.12 works well with perfect sound. No hiccups at all.

I am running 83.xxxxx.77 official version of chromeos on an acer 14" Chromebook. I have tried many things to try to get some version of Puredata to work. I have used apt-get to install pd-version 0.49.x. I have downloaded and built from source pd versions 0.50.2 and 0.51 (brand-new). Every version runs and makes a similar complaint both on the command line and in the running program (see below):

"priority X scheduling failed; running at normal priority" - where X is 94, 92, 8 or 6.

I have tried multiple command line switches and setup parameters all with the same results. Additionally, as you can see from the screencapture below, once DSP is turned on the helpful 'Audio I/O error' message is displayed. I have researched and tried many things including adding the audio group and my name to '/etc/security/limits.conf' with the same result. Also, I have run pd without realtime scheduling: 'pd -nrt' with the same scratchy sound results.
I would be extremely grateful to anyone who could help me solve this problem or point me in the right direction. Perhaps I am missing something simple and/or obvious. Thank you in Advance!