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:
how does [list drip] actually work?
This is going to be a weird and long post, because I am walking through my thinking as much as I am asking questions. Sorry for the length in advance.
I've recently become fascinated with the many possibilities afforded by the list-abs library, and what strikes me at is that [list-drip] seems to be at the heart of most of them. For those of you who don't know, [list-drip] works by separating (aka "dripping") an incoming list into its individual elements (atoms?). This allows you to do a bunch of operations on these elements before repacking them into a new list. For example, [list-compare] functions like [==] but for lists by checking each list's elements against each other to give out a binary yes or no answer. And of course, [list-drip] is at the core here.
I would like to really figure out the logic behind [list-drip], but the help file (well, really the abstraction itself) is deceptively simple. This is because [list-drip] itself is but an abstraction based on the clever use of [list-split] (which is not an abstraction but an external) and some strange binary math and triggering mechanisms that I don't understand.
Here's the [list-drip] extraction itself:
I'll just talk about this abstraction and ask questions along the way.
Here's the first part. Pretty simple. [trigger] is passing the entire list on, and then sending a bang. This seems weird but I've heard that pd will take care of all the operations starting at the right outlet of trigger first, so the bang is guaranteed to come after the list has been "dripped."
Here's the second part, where we have [list split] doing a binary "less than" operation on the list. "If the list is less than 2 elements long, it gets sent to the outlet and the [spigot] closes, else, open the spigot." This [trigger] then passes a copy of the list onto [spigot] which is either open or closed based on the above result.
Ok now here is where things start to get crazy. The list is now fed into two identical [list split] mechanisms with some weird math going on, which are also feeding back into the top of the second [trigger].
Let's break this down really quick:
First, we get the length of the list, then we feed it into [>> 1]. With some research in pd and the on the web, I come to the conclusion that we are basically dividing (integer division) by 2. This is setting the point for where [list split] outputs a list with only a certain number (but always half) of elements (using the first outlet). As I said before, this result is being fed back into the second [trigger].
So I think basically what's happening is this:
...where the rest of the list is either exactly half the total list length (if it's an even number) or half + 1 (if the total length is an odd number of elements).
So we have two "loops" going on here, where on operates on the first half of the list (will call this the "red" loop, and the other operates on the second "green loop".
Now in terms of trigger ordering, what is happening here? Are we constantly triggering the red loop until there are no more operations, and then moving on the green loop? And what does this mean in the context of the patch? I'm confused about how [trigger] acts in these situations with many nested loops.
To troubleshoot, I attached a print the outlets of both the red and green **[list split]**s, and sent the list [a b c d 1 2 3 4( to [list drip]. Here's the output from the console:
first half: symbol a second half: symbol b first half: list a b first half: symbol c second half: symbol d second half: list c d first half: list a b c d first half: 1 second half: 2 first half: 1 2 first half: 3 second half: 4 second half: 3 4 second half: 1 2 3 4
To me this output looks like it was printed backwards. Is there some weird interaction between [trigger] and [print] going on?
Furthermore, how is the output of [list drip] organized so that each element is output in it's sequential order? How does the green loop know to wait for the red loop to finish?
Control Parameter Scalling Issue -- Pd Vanilla
So I'm nearing completion of a somewhat large hardware control patch using Vanilla objects only in the most minimal and elegant manner I can come up with. It's mostly done, but there's one specific scaling issue that's holding things up ATM. I've come up with some ideas to solve the problem but those solutions are a bit ungainly and overly complex relative to the way I've coded the rest of the patch. So I'm interested if anyone on here has any better Vanilla-compatible ideas (trying to avoid use of externals here).
The hardware device has a number of parameters which can be accessed either by standard low-resolution midi control (0-127) OR by higher resolution system exclusive control (in one case, 0-164 thou the hi res max values vary between the different parameters being accessed). The patch contains dual sliders so that the parameters in question can be accessed both ways, and these sliders send data to both the receiving device to change the actual value as well as to a [set $1( message which is then connected to the other slider to reflect the updated value. Obviously this slider update value has to be compressed or expanded before being converted to the "set" value. That's not so much of a problem except that it has to replicate the same exact scaling that the hardware device uses or the updated value will be inaccurate relative to the adjusted hardware parameter.
For example, in the case of the 0-164 parameter, the hardware scales this to standard midi by jumping every 4th digit (so it drops 4, 8, 13, 17 etc from the hi res value). What is the simplest and most elegant way to add or subtract from the control range in order to replicate the same scaling in Pd Vanilla?