@Maggie17 Sometimes it is easier with words........

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
2. If the Dollar $ variable in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

David.

This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:

• reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.

• comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.

  • foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.

How playback works

• libpd sends a 1 to vol, then a bang to play.
  • Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].

• the length of the song is arbitrarily set by the user.
  • This affects the trackbar's cursor visibility and ability to set a position.
  • If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.

• The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].

How the mixer works

• all mixer controls go inside of [pd mix]

• horizontal and vertical sliders are turned into slider controls in the UI element
  • labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
  • min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
  • there are currently 7 sliders in the UI element

• bang objects with no label become simple buttons in the UI
  • their send symbols will be reflected in the button's name and they will send a bang when clicked.
  • there are currently 3 buttons

• bang objects with a label assigned become message buttons
  • these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
  • the bang's label is placed inside of the edit text field as a suggested message to send.
    • pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
  • there are currently 2 message buttons, with the 'any' button being a potential 3rd.

• a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
  • the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
  • also substitutes as a third normal message button, when the other two are already in use

• toggles become checkboxes
  • each checkbox can have a label and send symbol assigned to it
  • there are currently 4 checkboxes

• right-clicking a track shows the context menu entry Pd Player -> Load mixer.
  • basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.

foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.

I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds

foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST

ok dependencies seems to be ok...this is my log

fremen@fremenCPU MINGW64 ~
$ pacman -S autoconf automake git libtool \

make mingw-w64-x86_64-dlfcn mingw-w64-x86_64-fftw
mingw-w64-x86_64-fluidsynth
mingw-w64-x86_64-ftgl mingw-w64-x86_64-fribidi
mingw-w64-x86_64-ladspa-sdk mingw-w64-x86_64-lame
mingw-w64-x86_64-libsndfile mingw-w64-x86_64-libvorbis
mingw-w64-x86_64-lua mingw-w64-x86_64-toolchain
mingw-w64-x86_64-libjpeg-turbo
rsync unzip wget
warning: autoconf-2.69-3 is up to date -- reinstalling
warning: automake-wrapper-10-1 is up to date -- reinstalling
warning: git-2.10.1-1 is up to date -- reinstalling
warning: libtool-2.4.6-2 is up to date -- reinstalling
warning: make-4.2.1-1 is up to date -- reinstalling
:: There are 16 members in group mingw-w64-x86_64-toolchain:
:: Repository mingw64

1. mingw-w64-x86_64-binutils 2) mingw-w64-x86_64-crt-git
2. mingw-w64-x86_64-gcc 4) mingw-w64-x86_64-gcc-ada
3. mingw-w64-x86_64-gcc-fortran 6) mingw-w64-x86_64-gcc-libgfortran
4. mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-gcc-objc
5. mingw-w64-x86_64-gdb 10) mingw-w64-x86_64-headers-git
6. mingw-w64-x86_64-libmangle-git 12) mingw-w64-x86_64-libwinpthread-git
7. mingw-w64-x86_64-make 14) mingw-w64-x86_64-pkg-config
8. mingw-w64-x86_64-tools-git 16) mingw-w64-x86_64-winpthreads-git

Enter a selection (default=all):
warning: mingw-w64-x86_64-binutils-2.27-2 is up to date -- reinstalling
warning: mingw-w64-x86_64-crt-git-5.0.0.4745.d2384c2-1 is up to date -- reinstal ling
warning: mingw-w64-x86_64-gcc-6.2.0-2 is up to date -- reinstalling
warning: mingw-w64-x86_64-gcc-libgfortran-6.2.0-2 is up to date -- reinstalling
warning: mingw-w64-x86_64-gcc-libs-6.2.0-2 is up to date -- reinstalling
warning: mingw-w64-x86_64-headers-git-5.0.0.4747.0f8f626-1 is up to date -- rein stalling
warning: mingw-w64-x86_64-libwinpthread-git-5.0.0.4741.2c8939a-1 is up to date - - reinstalling
warning: mingw-w64-x86_64-winpthreads-git-5.0.0.4741.2c8939a-1 is up to date -- reinstalling
warning: unzip-6.0-2 is up to date -- reinstalling
warning: wget-1.18-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: mingw-w64-x86_64-gcc-libgfortran will be installed before its mingw-w64 -x86_64-gcc-libs dependency
warning: dependency cycle detected:
warning: mingw-w64-x86_64-harfbuzz will be installed before its mingw-w64-x86_64 -freetype dependency
warning: dependency cycle detected:
warning: mingw-w64-x86_64-cairo will be installed before its mingw-w64-x86_64-fr eetype dependency
warning: dependency cycle detected:
warning: mingw-w64-x86_64-fontconfig will be installed before its mingw-w64-x86_ 64-freetype dependency

Packages (58) mingw-w64-x86_64-cairo-1.15.2-4 mingw-w64-x86_64-flac-1.3.1-2
mingw-w64-x86_64-fontconfig-2.12.0-2
mingw-w64-x86_64-freetype-2.7-1 mingw-w64-x86_64-gdbm-1.12-1
mingw-w64-x86_64-glib2-2.50.1-2
mingw-w64-x86_64-graphite2-1.3.8-5
mingw-w64-x86_64-harfbuzz-1.3.2-1
mingw-w64-x86_64-libogg-1.3.2-2 mingw-w64-x86_64-libpng-1.6.26-1
mingw-w64-x86_64-ncurses-6.0.20161001-1
mingw-w64-x86_64-pcre-8.38-1 mingw-w64-x86_64-pixman-0.34.0-3
mingw-w64-x86_64-portaudio-19_20140130-2
mingw-w64-x86_64-python2-2.7.12-1
mingw-w64-x86_64-readline-6.3.008-1
mingw-w64-x86_64-speex-1.2rc2-2
mingw-w64-x86_64-speexdsp-1.2rc3-2 mingw-w64-x86_64-tcl-8.6.6-1
mingw-w64-x86_64-termcap-1.3.1-2 mingw-w64-x86_64-tk-8.6.6-1
mingw-w64-x86_64-wineditline-2.101-4 winpty-0.4.0-2
autoconf-2.69-3 automake-wrapper-10-1 git-2.10.1-1
libtool-2.4.6-2 make-4.2.1-1 mingw-w64-x86_64-binutils-2.27-2
mingw-w64-x86_64-crt-git-5.0.0.4745.d2384c2-1
mingw-w64-x86_64-dlfcn-1.0.0-2 mingw-w64-x86_64-fftw-3.3.5-1
mingw-w64-x86_64-fluidsynth-1.1.6-3
mingw-w64-x86_64-fribidi-0.19.7-1
mingw-w64-x86_64-ftgl-2.1.3rc5-2 mingw-w64-x86_64-gcc-6.2.0-2
mingw-w64-x86_64-gcc-ada-6.2.0-2
mingw-w64-x86_64-gcc-fortran-6.2.0-2
mingw-w64-x86_64-gcc-libgfortran-6.2.0-2
mingw-w64-x86_64-gcc-libs-6.2.0-2
mingw-w64-x86_64-gcc-objc-6.2.0-2 mingw-w64-x86_64-gdb-7.12-1
mingw-w64-x86_64-headers-git-5.0.0.4747.0f8f626-1
mingw-w64-x86_64-ladspa-sdk-1.13-2
mingw-w64-x86_64-lame-3.99.5-4
mingw-w64-x86_64-libjpeg-turbo-1.5.1-1
mingw-w64-x86_64-libmangle-git-5.0.0.4669.7de6266-1
mingw-w64-x86_64-libsndfile-1.0.26-1
mingw-w64-x86_64-libvorbis-1.3.5-1
mingw-w64-x86_64-libwinpthread-git-5.0.0.4741.2c8939a-1
mingw-w64-x86_64-lua-5.3.3-1
mingw-w64-x86_64-make-4.1.2351.a80a8b8-1
mingw-w64-x86_64-pkg-config-0.29.1-2
mingw-w64-x86_64-tools-git-5.0.0.4669.7de6266-1
mingw-w64-x86_64-winpthreads-git-5.0.0.4741.2c8939a-1
rsync-3.1.2-2 unzip-6.0-2 wget-1.18-1

Total Download Size: 76.81 MiB
Total Installed Size: 749.00 MiB
Net Upgrade Size: 369.69 MiB

:: Proceed with installation? [Y/n] Y
:: Retrieving packages...
mingw-w64-x86_64-dl... 9.6 KiB 9.41M/s 00:00 [#####################] 100%
mingw-w64-x86_64-ff... 4.0 MiB 1146K/s 00:04 [#####################] 100%
mingw-w64-x86_64-wi... 32.7 KiB 6.39M/s 00:00 [#####################] 100%
mingw-w64-x86_64-pc... 859.1 KiB 1252K/s 00:01 [#####################] 100%
mingw-w64-x86_64-gl... 2.9 MiB 1247K/s 00:02 [#####################] 100%
mingw-w64-x86_64-li... 191.2 KiB 7.18M/s 00:00 [#####################] 100%
mingw-w64-x86_64-fl... 582.7 KiB 1588K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 331.2 KiB 1761K/s 00:00 [#####################] 100%
mingw-w64-x86_64-sp... 472.2 KiB 1349K/s 00:00 [#####################] 100%
mingw-w64-x86_64-sp... 519.0 KiB 1458K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 359.9 KiB 1874K/s 00:00 [#####################] 100%
mingw-w64-x86_64-po... 143.6 KiB 7.01M/s 00:00 [#####################] 100%
mingw-w64-x86_64-fl... 252.2 KiB 1425K/s 00:00 [#####################] 100%
mingw-w64-x86_64-fo... 220.8 KiB 1284K/s 00:00 [#####################] 100%
mingw-w64-x86_64-pi... 289.5 KiB 1591K/s 00:00 [#####################] 100%
mingw-w64-x86_64-ca... 755.8 KiB 1423K/s 00:01 [#####################] 100%
mingw-w64-x86_64-gr... 167.0 KiB 7.09M/s 00:00 [#####################] 100%
mingw-w64-x86_64-ha... 314.4 KiB 1700K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 285.9 KiB 1571K/s 00:00 [#####################] 100%
mingw-w64-x86_64-fr... 503.3 KiB 1422K/s 00:00 [#####################] 100%
mingw-w64-x86_64-ft... 118.8 KiB 7.25M/s 00:00 [#####################] 100%
mingw-w64-x86_64-fr... 93.4 KiB 7.02M/s 00:00 [#####################] 100%
mingw-w64-x86_64-la... 8.3 KiB 8.13M/s 00:00 [#####################] 100%
mingw-w64-x86_64-la... 373.9 KiB 1928K/s 00:00 [#####################] 100%
mingw-w64-x86_64-lu... 269.6 KiB 1506K/s 00:00 [#####################] 100%
mingw-w64-x86_64-gc... 18.0 MiB 1203K/s 00:15 [#####################] 100%
mingw-w64-x86_64-gc... 8.1 MiB 1209K/s 00:07 [#####################] 100%
mingw-w64-x86_64-gc... 13.6 MiB 1202K/s 00:12 [#####################] 100%
mingw-w64-x86_64-gd... 164.1 KiB 6.97M/s 00:00 [#####################] 100%
mingw-w64-x86_64-nc... 1697.2 KiB 1237K/s 00:01 [#####################] 100%
mingw-w64-x86_64-te... 12.6 KiB 12.3M/s 00:00 [#####################] 100%
mingw-w64-x86_64-re... 327.4 KiB 1732K/s 00:00 [#####################] 100%
mingw-w64-x86_64-tc... 2.9 MiB 1242K/s 00:02 [#####################] 100%
mingw-w64-x86_64-tk... 1873.6 KiB 1218K/s 00:02 [#####################] 100%
mingw-w64-x86_64-py... 11.2 MiB 1216K/s 00:09 [#####################] 100%
mingw-w64-x86_64-gd... 2.9 MiB 1234K/s 00:02 [#####################] 100%
mingw-w64-x86_64-li... 26.7 KiB 6.51M/s 00:00 [#####################] 100%
mingw-w64-x86_64-ma... 103.2 KiB 7.20M/s 00:00 [#####################] 100%
mingw-w64-x86_64-pk... 237.5 KiB 1357K/s 00:00 [#####################] 100%
mingw-w64-x86_64-to... 257.4 KiB 1446K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 379.7 KiB 1957K/s 00:00 [#####################] 100%
winpty-0.4.0-2-x86_64 495.6 KiB 1404K/s 00:00 [#####################] 100%
rsync-3.1.2-2-x86_64 259.9 KiB 1460K/s 00:00 [#####################] 100%
wget-1.18-1-x86_64 582.1 KiB 1595K/s 00:00 [#####################] 100%
(58/58) checking keys in keyring [#####################] 100%
(58/58) checking package integrity [#####################] 100%
(58/58) loading package files [#####################] 100%
(58/58) checking for file conflicts [#####################] 100%
(58/58) checking available disk space [#####################] 100%
warning: could not get file information for usr/share/man/man3/Git::I18N.3pm.gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Editor. 3pm.gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Fetcher .3pm.gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Memoize ::YAML.3pm.gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Prompt. 3pm.gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Ra.3pm. gz
warning: could not get file information for usr/share/man/man3/Git::SVN::Utils.3 pm.gz
:: Processing package changes...
( 1/58) reinstalling autoconf [#####################] 100%
( 2/58) reinstalling automake-wrapper [#####################] 100%
( 3/58) reinstalling git [#####################] 100%
( 4/58) reinstalling libtool [#####################] 100%
( 5/58) reinstalling make [#####################] 100%
( 6/58) reinstalling mingw-w64-x86_64-libwinpt... [#####################] 100%
( 7/58) reinstalling mingw-w64-x86_64-gcc-libg... [#####################] 100%
( 8/58) reinstalling mingw-w64-x86_64-gcc-libs [#####################] 100%
( 9/58) installing mingw-w64-x86_64-dlfcn [#####################] 100%
(10/58) installing mingw-w64-x86_64-fftw [#####################] 100%
(11/58) installing mingw-w64-x86_64-wineditline [#####################] 100%
(12/58) installing mingw-w64-x86_64-pcre [#####################] 100%
(13/58) installing mingw-w64-x86_64-glib2 [#####################] 100%
No schema files found: doing nothing.
(14/58) installing mingw-w64-x86_64-libogg [#####################] 100%
(15/58) installing mingw-w64-x86_64-flac [#####################] 100%
(16/58) installing mingw-w64-x86_64-libvorbis [#####################] 100%
(17/58) installing mingw-w64-x86_64-speexdsp [#####################] 100%
(18/58) installing mingw-w64-x86_64-speex [#####################] 100%
(19/58) installing mingw-w64-x86_64-libsndfile [#####################] 100%
(20/58) installing mingw-w64-x86_64-portaudio [#####################] 100%
(21/58) installing mingw-w64-x86_64-fluidsynth [#####################] 100%
(22/58) installing mingw-w64-x86_64-fontconfig [#####################] 100%

Fontconfig configuration is done via /mingw64/etc/fonts/conf.avail and conf.d.
Read /mingw64/etc/fonts/conf.d/README for more information.

updating font cache... C:/msys64/mingw64/bin/fc-cache.exe: error while loading s hared libraries: ?: cannot open shared object file: No such file or directory
done.
(23/58) installing mingw-w64-x86_64-pixman [#####################] 100%
(24/58) installing mingw-w64-x86_64-cairo [#####################] 100%
Optional dependencies for mingw-w64-x86_64-cairo
mingw-w64-x86_64-glib2: libcairo-gobject [installed]
(25/58) installing mingw-w64-x86_64-graphite2 [#####################] 100%
(26/58) installing mingw-w64-x86_64-harfbuzz [#####################] 100%
Optional dependencies for mingw-w64-x86_64-harfbuzz
mingw-w64-x86_64-icu: harfbuzz-icu support
(27/58) installing mingw-w64-x86_64-libpng [#####################] 100%
(28/58) installing mingw-w64-x86_64-freetype [#####################] 100%
(29/58) installing mingw-w64-x86_64-ftgl [#####################] 100%
(30/58) installing mingw-w64-x86_64-fribidi [#####################] 100%
(31/58) installing mingw-w64-x86_64-ladspa-sdk [#####################] 100%
(32/58) installing mingw-w64-x86_64-lame [#####################] 100%
(33/58) installing winpty [#####################] 100%
(34/58) installing mingw-w64-x86_64-lua [#####################] 100%
(35/58) reinstalling mingw-w64-x86_64-binutils [#####################] 100%
(36/58) reinstalling mingw-w64-x86_64-headers-git [#####################] 100%
(37/58) reinstalling mingw-w64-x86_64-crt-git [#####################] 100%
(38/58) reinstalling mingw-w64-x86_64-winpthre... [#####################] 100%
(39/58) reinstalling mingw-w64-x86_64-gcc [#####################] 100%
(40/58) installing mingw-w64-x86_64-gcc-ada [#####################] 100%
(41/58) installing mingw-w64-x86_64-gcc-fortran [#####################] 100%
(42/58) installing mingw-w64-x86_64-gcc-objc [#####################] 100%
(43/58) installing mingw-w64-x86_64-gdbm [#####################] 100%
(44/58) installing mingw-w64-x86_64-ncurses [#####################] 100%
(45/58) installing mingw-w64-x86_64-termcap [#####################] 100%
(46/58) installing mingw-w64-x86_64-readline [#####################] 100%
(47/58) installing mingw-w64-x86_64-tcl [#####################] 100%
(48/58) installing mingw-w64-x86_64-tk [#####################] 100%
(49/58) installing mingw-w64-x86_64-python2 [#####################] 100%
(50/58) installing mingw-w64-x86_64-gdb [#####################] 100%
(51/58) installing mingw-w64-x86_64-libmangle-git [#####################] 100%
(52/58) installing mingw-w64-x86_64-make [#####################] 100%
(53/58) installing mingw-w64-x86_64-pkg-config [#####################] 100%
(54/58) installing mingw-w64-x86_64-tools-git [#####################] 100%
(55/58) installing mingw-w64-x86_64-libjpeg-turbo [#####################] 100%
(56/58) installing rsync [#####################] 100%
(57/58) reinstalling unzip [#####################] 100%
(58/58) reinstalling wget [#####################] 100%

@cuinjune I tried to compile the lissa seq patch. but when i open the executable it opens only a small empty window.
i also tried to compile a help patch for testing, with the same result.
but your example works fine(Win32Example).

@Fauveboy I have started but I don't have time to finish (flight to Prague waiting).......
Yes, you can have just one gridSampler. It is about the most important thing to learn as you advance with Pd.

like this.zip

I have changed the table name and some of the send/receive objects so you can see the principle.
Change every send, receive, send~, receive~, throw~, catch~ .......
Add a $1 to their names and they become unique in every copy of the abstraction [gridSampler X]

so change (for example) [r phasea] to [r $1-phasea]

If you are sending or receiving information from outside the abstraction use the value of $1...... the argument of the [gridSampler] you want to communicate with.
So to send to [gridSampler 1] use [s 1-phasea]........ to send to [gridSampler 2] use [s 2-phasea]

Inside the abstraction $........ outside it's value....... its value in its name too (it is outside)..... see example above...
Every $ (in an object... not in a message) will be given the value (become that value) when the abstraction is created.

David.

@whale-av Hello again, thank you very much for replying so quickly!

Ok so, the computer will always be a PC and will always have Pd installed so that makes things a lot easier I suppose (not sure what version it will be though, but since all those computers have only recently been equipped with Pd I'm assuming it's either vanilla or extended so it should be ok).
I just put my 17 sound files in the same folder and named them 1.wav ...... 17.wav. They are in the same folder as your patch now too.
Well, the numbers are not exactly "set", in fact, each sound file corresponds to a certain range of numbers. Ugh, I did it again, forgot to mention the range... Sorry..... I'd probably need a different object for a range... It's still kinda difficult for me to think in "computer" language about things related to music so that's why I'm forgetting to mention tons of stuff, but I'll try to fix that in this reply, sorry again!
I will just post the table to make it easier for you to understand.

But first, I would just like to explain how the table works. First I need to ask if it's possible to attribute the same numbers/range to different sound files, depending on the number's "place" within the combination? (You'll understand once you see the table.) Maybe it isn't and in that case I should think of a way to change the table according to what can be done?
So, there should be 13 numbers in total within the combination (13 numbers to type, like 13 empty slots waiting to be filled with numbers), but I said there are five sub-combinations. The first, second and fourth are 2 digit numbers, the third is a 3 digit number and the fifth is a 4 digit number. Obviously, three of these are 2 digit numbers, but the thing is I can't really choose the ranges (I have a set range for each sub-combination and can only try to figure out the easiest way to work with them) and the ranges are actually intertwined, So some numbers can be repeated, that's why I'm asking if the same numbers can be attributed to different sound files based on whether it's the first, second or fourth sub-combination. If that's too complicated or even impossible, I can only think of sacrificing a couple of sound files and just let the program play the same file twice instead.

Also important: is it possible to "condition" to program into playing a sound file based on the first combination, the first 2 digit number? Simply put through simple chords, say in the first combination you can type either 01 or 02, where 01 is A major and 02 is B major. Next, you can type in either 02 or 03, where 03 is E major (irrelevant right now), but 02 can be either D major or F sharp major (not A major like in the first combination), based on what the previous number was. If it was 01 (A major), then this time 02 will be D major, but if the first number was 02 (B major) then the 02 in the second combination should be F sharp major. IS something like this even possible, or do I need to figure out a way to go around this and alter my table? I CAN alter the table, but I can't work with the ranges of the combinations, or the number of the combinations, it must be 5.
Lastly, can different numbers be attributed to the same sound file based on their position within the combination?

Ok so finally here's the table, and I will just give you my current table so you can tell me if it's possible to do. I understand if it's too complicated and I need to change it! Maybe you can give me some tips on how to change it to make it the easiest to do in Pd.
1st SUB-COMBINATION
01-19 - 1.wav
20-22 - 2.wav
23-31 - 3.wav
2nd SUB-COMB.
01-03 - 4.wav (if the first was 01-19 or 20-22; or shorter, 01-22)
01-03 - 5.wav (if the first was 23-31)
04-06 - 6.wav
07-09 - 7.wav (if the first was 01-19)
07-09 - 8.wav (if the first was 20-31)
10-12 - 9.wav (if the first was 01-19)
10-12 - 10.wav (if the first was 20-22)
10-22 - 11.wav (if the first was 23-31)
3rd SUB-COMB.
900-975 - 4.wav (if the first was 01-19)
900-975 - 2.wav (if the first was 20-22)
900-975 - 12.wav (if the first was 23-31)
976-999 and 000-020 - 1.wav (if the first was 10-22)
976-999 and 000-020 - 13.wav (if the first was 23-31)
4th SUB-COMB.
01-09 - 7.wav (if the first was 01-19)
01-09 - 8.wav (if the first was 20-31)
10-69 - 14.wav (if the first was 01-19)
10-69 - 3.wav (if the first was 20-31)
70-99 - 6.wav (if the first was 01-22)
70-99 - 11.wav (if the first was 23-31)
5th SUB-COMB.
(this one is arbitrary so no matter what the last 4 numbers are, the sound file that is triggered should be based on the first combination, or something like that, so...)
xxxx - 15.wav (if the first was 01-19)
xxxx - 16.wav (if the first was 20-22)
xxxx - 17.wav (if the first was 23-31)

Now, I need to thank you if you had the patience to actually read all that and think about it..... I can only hope you could understand the idea, but please, if this is just too complicated, do tell me to change the table. Maybe, if you can or think I will understand, try to explain how the ranges work when playing sound files and how I can use that to my advantage to still keep all the sound files (or as many as possible) but make the thing easier to program.

Now I know I had a few more questions but I can't remember right now and I don't want to bombard you with everything all at once, I realize even this is way more than I could have asked for, you have been a huge help, really! Even if I don't entirely understand every single element of your patches, I did study them and used the help option like you advised me to, so I really am trying to get the hang of this. I completely understand if you just want to take a break from this if it's too complicated and time-consuming, I just ask that you give me some kind of feedback so I know what to expect!

Anyway, thank you for all your help and guidance until now, and for the guidance you'll provide in the future if you so choose!

Ok...... So I have been meaning to do this for a very long time......
I don't think it is the perfect "show_me_dollars" and so I will change it from time to time.
3rd attempt.........
show_me_dollars.zip
Here is a really terrifying screenshot, but I have also tried to explain it in words.
In many ways I think words ( below the screenshot) are easier to understand.
David.

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
   Use it also for objects like [delwrite~ $0-buffer 100] or for an array name [array $0-array] so that in each abstraction they have a different name and you will not have problems with their being "multiply defined"...... as each name can only exist once in your patch.

2. If the Dollar $ variable is in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

P.S. If the first item in the incoming list is a symbol then it will be dropped causing errors.
You can fix that by making the message a list by passing it through the object [list].
Unfortunately only messages starting with a float are automatically recognised as lists.

If you want to send a text message with a number you just make a message box containing the info you want to send and connect it to [send xyz] and then bang the message at the same time you send the variable, then you can [receive xyz] at the other end. (if you want to do that automatically whenever you change a number then just connect the output of the number box to the input of the message box).
You can't send both a number and text in the same send & receive box unless you start packing them into lists... probably simpler just to use 1 send & receive pair for the number and 1 send & receive pair for the text.

It's not that elegant!
In writing sequences I haven't found a need to send text with numbers. Just label stuff with comments to help you see where it's going.

I haven't seen your patch but possibly a way to make it more efficient is to bear in mind that if the numbers for each step are stored in the number boxes or sliders used to edit the sequencer, then they don't need to be additionally stored anywhere else unless you are saving/loading patterns. If you want pattern storage then, yes, you will need some pretty intense messaging to exchange the data between the displayed/currently played sequence and the memory banks.

New version 7 (currently testing)

• added automatic loosening of minimum fitness limit for the case that a population of sounds gets stuck in a local maximum in the fitness landscape (really nerdy jabbering, but trust me, it's useful ^^)
• added automatic "jumping" out of local maximums after a certain number of fruitless climbing-trials

EWOLVERINE v.7 by Henry Dalcke.pd

plans:
• bugfix: prevent a newly audible sound from being selected after manually stopping the target drive
• simulated annealing in target drive mode: span "temperature" value onto fitnesslandscape and decrease step length (modwheel) and probability value in the splice-pattern-generator the closer the fitness gets to optimal fitness value
• interactive mode: automatic narrowing of the range of generated parameter values around a mean value that's derived from the repeated selection of similar values of individual parameters throughout the generations (increases the number of similar sounds per generation that are located around a certain coordinate in parameter space; increases the likelihood of the generation of the desired sound in a smaller amount of time)
• stop-condition for automatic stopping of target drive
• make default settings for modwheel-position, splice-pattern-generator's probability, anti-stuck and allowed minimum fitness value in target drive adjustable from GUI
• adjustable MIDI output message blocker (useful for instruments with a fixed MIDI implementation, for instance: If you want to breed a bass drum in a drum synth with multiple instruments, you may not want to ruin the parameter adjustments of the snare drum meanwhile you're selecting for good bass drums)
• storage for self-created splicer patterns (maybe in connection to the MIDI output message blocker)
• low-value-weighted probability for the generation of MIDI-CC-values in new populations; switchable per MIDI-CC either manually or randomly (increases the probability for the generation of short attack and decay values in synth's envelopes)
• bigger populations for each sound-set: 4 more random sounds per set (A/B) to select from
• discontinuous MIDI messaging interrupted by assignment switching CC events (special build for FM-Heaven) - low priority
• possibility to interpolate between new random population's sounds to smoothly re-direct the modwheel-morphing path while morphing
• selection-history recorder that one can use to re-load the selected sounds of each past generation
• a visualizer that generates a "tree of life" from directions (keys C,D,E,F) and steplengths (modwheel) of formerly selected individuals and their respective distances to their parent sounds

limitations

• uses dynamic patching (can cause audio glitches).
• while creating new abstractions the connection can be lost and has to be reset manually by clicking the reset bang.
• still sends errors to the console /( anyone have any ideas on how to get rid of these? )

|@#¢|#∞¢∞¬÷“¬”≠´´‚ø †¥∫ƒ€å∂∫∂ƒ™¶ƒµ ©ß∑√Ω≤.zip