Wavetable Drum Machine - repost
I uploaded this Wavetable Drum Machine last year but it became a casualty of a server issue (I hope it didn't cause it, it is a bit heavy). Anyway it didn't work under windows so while I was updating old drum machines I sorted this one out.
Here's the instructions, which are also under the Balwyn button.
Wavetable Drum Machine
8 x bank of 64 amplitude sliders, each bank runs in sync driven by a clock. The clock has 16 start/end settings plus a repeat cycles setting, there is also a Vradio block to set the return position.
The mixer block has 8 x level & pan settings with stereo to the dac~
The wave selector is for loading the individual wav files to the relevant drum line. The *.wav files must be stored in the 'waves' folder within the program folder and selected from there.
Saving must be saved to the 'pattern' folder within the program folder. Save the file with one word and no extension, a file of that name will be created for the pattern settings. Another file with the same name will also be created with the extension '.kit', this stores the names of the wave files.
Loading must be from the 'pattern' folder within the program folder. All the clock, pattern and wave files will be updated. select only the file WITHOUT the .kit extension, otherwise nothing will load and soundfiler errors will appear in the Pd window.
The clear button will clear all the amplitude sliders, set all the clock settings to 1 except BPM which is set to 500.
The supplied samples were recorded via Audacity from Qsynth. Ditch them for your own
Is there a function that works like a table but with only one value?
in short: it's 1 float stored in 1 object of a separate data structure referenced by a pointer in each value object
in longer: when you create a value object with a given name. it checks to see whether a second class called vcommon has any objects that share the same name as the new value object. If not, it creates a vcommon object with that name and stores the float value inside. Then the value stores the pointer to this float and looks up that float using a pointer whenever it needs to modify or get the value (as do all of the other value objects that share the same name). The vcommon object knows how many value objects share it's name (a "reference count") and when the last value object with the same name is deleted, so is the vcommon object
Need help with patch for a glitch project
@Sarabade Hello Sarabade......
If you google the wikepedia pages for all the different file formats for video and still images you will see that all of the files will have a header, which tells the operating system how to interpret the file (even the uncompressed formats like .bmp). If you glitch (corrupt) the header then the file cannot be read.
So you must not corrupt the data until you are a few (or a few thousand) bytes into the file (how many depends upon the file format...... jpg, tiff, bmp etc..)
I have found Antonio Roberts file on my computer and modded it to send out the ascii codes...... it might provide a start for your project........
JPG - binary - killer_mod.pd
Look into (right-click-open) one of the green abstraction boxes to see how you could write your new file..... and save it......... and importantly how you can avoid modifying the header.......
You cannot use [send glitch_ascii_code_list] as the header codes are already broken!!...... it is just for viewing in the terminal...........
If you try to write the actual ascii "symbols" to a message file then you will get the "closing brace" messages that you are seeing.......or worse! Pd will try to interpret some characters as "control" messages, and that will crash Pd. You will have to work with the numbers that represent the "characters" (ascii or binary) and not the "text" characters....a,b,c, etc......
install pdl2ork on manjaro: fails to get flite installed..
Hi there, i also posted to the manjaro forum but i guess here i can find more expertise on that topic: i want to install pd-l2ork on manjaro (arch-based) linux and I get this error building flite:
Insert Co> Found flite1.patch ==> Validating source files with md5sums... flite-1.4-release.tar.bz2 ... Passed flite1.patch ... Passed ==> Extracting sources... -> Extracting flite-1.4-release.tar.bz2 with bsdtar ==> Starting prepare()... patching file config/common_make_rules ==> Starting build()... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for ar... ar checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for mmap... yes checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking machine/soundcard.h usability... no checking machine/soundcard.h presence... no checking for machine/soundcard.h... no checking sys/audioio.h usability... no checking sys/audioio.h presence... no checking for sys/audioio.h... no checking mmsystem.h usability... no checking mmsystem.h presence... no checking for mmsystem.h... no configure: creating ./config.status config.status: creating config/config config.status: creating config/system.mak making in ... making in include ... making in src ... making in src/audio ... gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auclient.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auclient.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auserver.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auserver.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c audio.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/audio.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_streaming.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_streaming.os au_streaming.c: In function ‘audio_stream_chunk’: au_streaming.c:77:9: warning: variable ‘n’ set but not used [-Wunused-but-set-variable] int n; ^ gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_oss.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_oss.os au_oss.c: In function ‘audio_open_oss’: au_oss.c:86:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ad->platform_data = (void *)afd; ^ au_oss.c: In function ‘audio_close_oss’: au_oss.c:181:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c:182:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] rv = close((int)ad->platform_data); ^ au_oss.c: In function ‘audio_write_oss’: au_oss.c:189:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return write((int)ad->platform_data,samples,num_bytes); ^ au_oss.c: In function ‘audio_flush_oss’: au_oss.c:194:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c: In function ‘audio_drain_oss’: au_oss.c:199:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_RESET, NULL); ^ ar: ../../..//tmp/yaourt-tmp-kalimerox/aur-flite1/lib/libflite.shared.a: No such file or directory make: *** [../../config/common_make_rules:116: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/.build_so] Error 1 make: *** [../config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/.make_build_dirs] Error 2 make: *** [config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj//.make_build_dirs] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build flite1. de
anyone having the same issues or an advice=? ?
Idea for Effects Stack(ing) Technique/Control ("Mother")
To begin, I apologize in advance for this Not being a complete abstraction, so please forgive me for that.
As apology, I offer my humility: 10 hours-straight work later, I know some of what i thought of is beyond my knowledge limit and capacity to continue working on.
That all being said,...
My idea (which I thought would be Very simple, yet learned that PD, no matter how sweet She is, does not behave like the linux shell) was simple:
Make a rack of a set of vradios (i chose 8 due to the cpu limit on my laptop, but more could easily be added) which each denote a set of effects;
Send the results to a shell control along with the "slot" in the stack;
Have it copy that effect into an eff(ects)/tmp folder (mapping over the dummy files that were there),
so when the adc~ > eff1 > eff2, etc., chain runs they would be loaded as copies of the desired effects abstractions.
My intention was to empower the usage of multiple instances of the same effects abstractions as well as cut the wiring required in many/my pedal rack/s I have seen to almost nil.
That Was accomplished.
And I DO like the "idea".
On the other hand, I learned, to my chagrin, 2 VERY important lessons:
- pd loads all subpatches on startup
- there is no (this is were I bow to higher minds than myself) way to "refresh" the patch, shy of closing and reopening it (because while you can do this sort of thing in linux, you can not in pd "underwrite" a subpatch and presume it will know the change has been made).
I Did pursue trying to load via "cat" the effect file-contents into a pd (sub)patch object, but could not figure out how to make that work, even with subtracting the file accouterments, i.e.#X, #N.
In closing I will say that the goal, though only partially achieved, IS one worth pursuing if it is a domain you are more knowledgeable about than myself.
I have attached a zip of my work.
a shell script to start extended (it must be started this way, if the shell object is to know where the resource folder is located;
a folder, "res", which includes: /effs (where you put your effects abstractions), /effs_tmp (with 8 dummy files, where your effs get copied to), and /helper (where Mother is located)
a Mother_effsmap.txt file, where you list your effects, by filename (including the ".pd" extension", which it cross-references the vradio index to the line number on the file to know which file to copy.
I have found that it does copy correctly, but then you are left with the stack of controls to contend with. But I have yet to figure that out and think it better to go ahead and share it.
-peace, thanks for listening, and I hope it gives you some new ideas to work with.
I think perhaps one of the problems expressed here (though I'm not sure which one!) has to do with the dual-precision internal processing vs. single-precision external save/retrieve limitation present in all versions of Pd, with the exception (I assume, haven't tried it yet) of the experimental dual-precision build that was produced some time ago.
I unexpectedly ran into the issue myself when trying to set up dynamic color programming of the GUI objects after making a whole panel of them using the preset colors from the preferences panel. I noticed immediately that most of the 0-29 preset color numbers that I sent with messages obviously didn't quite match the 30 presets available in the panel grid. So I tried grabbing the RGB values instead by plugging them into the "pd RGB" calculator that's part of the GUI color edit help patch. Those wouldn't save properly. I must assume at this point that it's because those panel colors are all linked internally in Pd to the 6 digit hex value you can see in the "compose color" RGB pop-up panel. Many of those hex values translate to dual-precision decimal numbers, (which can't be saved without the app rounding them off) and on the external user-programmable level Pd only works with decimals, not hex.
What it comes down to is that although you can enter or generate dual-precision decimal values in realtime (like with "pd RGB"). You can't save/retrieve them without the numbers getting rounded.
My workaround to match the panel presets was to just fudge the single-precision decimals till I got it "close enough". The only other workaround I can think of to get it exactly right is to save the three RGB numbers as a list and then feed them with [unpack] to the pd RGB calc and embed the whole blob into the patch every time I wanted to switch some colors.
The various Pd sites and lists have a number of write-ups about the dual/single precision issues. There's also some stuff on the list somewhere about the 2 different sets of preset colors (I think the remote-switchable preset values all translate to single precision dec values, not sure). Don't have any links on hand ATM but the info can be found in many bits and pieces (like most of the info on this platform) if anyone is more interested in this topic.
gui externals tutorial ?
so I think the linker should be set to -lCicmWrapper but I got conflicts and undefined
can you help me out ?
cc -rdynamic -shared -L"D:/WORK/DSP/pd-0.46-7/src" -L"D:/WORK/DSP/pd-0.46-7/bin" -o "src/adsr.dll" "src/adsr.o" -L"D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs" -lCicmWrapper -lc -lpd D:/WORK/DSP/pd-0.46-7/bin/pd.lib(pd.dll):(.text+0x0): multiple definition of `error' /usr/lib/libc.a(t-d000927.o):fake:(.text+0x0): first defined here D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs/libCicmWrapper.a(libCicmWrapper_la-ecommon.o): In function `epd_add_folder': /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:578: undefined reference to `sys_searchpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `sys_staticpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `namelist_append_files' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `sys_staticpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `namelist_append_files'```
my question is very simple but I don't think I will find a simple solution. I would like to generate few random values.
Here is what I found:
random object: creates the same "random" values every time you open the patch
shuffle object : works but you can not have the same value before all values sent once ( also first bang always sends the same value)
true-random object: works but has a bug as sometimes sends values higher than the set high value
cpu time object: does not work
time object: creates a different value every time you run the patch , BUT my problem here is that if you want to have 10 different values will not be able to do it.
You can multiply milliseconds with minutes or adding hours with minutes and milliseconds to get different random numbers but that is too much I think.
- list item
Grid Sequencer/16 step sequencer
since you wanted to understand how they work, i'll try a brief description:
the values for the toggles and sliders are stored in tables internal to the abstraction. This way, when you want to know the value for a certain step, a simple table lookup is all that is required, rather than selecting the correct number from a list. this is more computationally efficient. The tabread in each patch is the table lookup
whenever values are changed in the abstractions, the value of the table at that index is changed as well. (this is the lower tab write part)
[tabdump] from zexy dumps the values of the sequence at the right outlet
The route stuff at the top is just to be able to intercept the messages to the abstractions.
and cycle count works by counting up until a limit is reached, then resetting cup
in mseq, the receives for setboxes are to link the sliders and the number boxes, but to use the "set" message on the number boxes so that there won't be an infinite loop when changing the sliders (because the value would go from slider to # box to slider to #box to slider etc)
and the way that they are combined to turn steps off in the mseq helpfile:
the step from cycle count is stored in a float object, and then sent to tseq. if the step is toggled on, tseq will put out a bang, sending the step value from the float object into mseq, which gets the value
Hi David, I am also David.
m0oonlib doesn't come with Pd-vanilla, but I am willing to get Pd-extended working (I'm actually prototyping for a patch that will run on a raspberry pi.) I definitely want to share these patches when I'm done, so I am using relative paths because I want it to run on different environments, with different file structures, with everything relative to the main patch.
declare /synths wouldn't that be an absolute location (at the root of my filesystem?)
open messages require 2 params, the second of which is the path. If you leave it off you will get this error:
Bad arguments for message 'open' to object 'pd'
I have tried it several ways, and all do not work:
(I get the
Bad Argument error)
With all of these I get
Device not configured:
These work, but are not ideal:
I'd prefer not hardcoding an absolute path.
moonlib/absolutepath doesn't seem to work with a directory name, only a file. That means this works:
But not this (the format I actually need for path):
This works, but really I'd just prefer a solution that works in Pd-vanilla: