all possible permutations with repetitions of harmonic volume from top to bottom
Hello there, is there a way to go through all possible permutations with repetitions of given data? for example, I have 16 slots for harmonics and each letter represents a different percentage in volume from 0 to 100%, "e" could represent 13% if you want: (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p). Im using Iannix to control Pure Data so I imagine that in iannix when the curve is at the top it will start with all possible combinations and permutations with repetitions and when the curve is at the bottom it will end, and have gone through all possible combinations.
Im aware of the number of combinations possible and their vast space, with 5 slots for harmonics with a,b,c,d,e for volume, with its repetitions and permutations I got 3126 different combinations or timbres.
For example: the category for using 5 harmonic slots with 4 different volumes and one repetition of volume is this:
(if you have repetitions one letter will be left out)
1.-aabcd 2.-aabdc 3.- aacbd 4.- aacdb 5.- aadbc 6.-aadcb 7.-abacd 8.-abadc 9.-abcad 10.-abcda 11.-abdac
12.- abdca 13.- acabd 14.-acadb 15.-acbad 16.- acbda 17.-acdab 18.- acdba 19.-adabc 20.- adacb
21.- adbac 22.-adbca 23.-adcab 24.- adcba 25.-baacd 26.-baadc 27.-bacad 28.- bacda 29.-badac 30.-badca
31.-bcaad 32.- bcada 33.-bcdaa 34.-bdaac 35.- bdaca 36.-bdcaa 37.-caabd 38.-caadb 39.-cabad 40.-cabda
41.-cadab 42.-cadba 43.-cbaad 44.-cbada 45.-cbdaa 46.-cdaab 47.-cdaba 48.-cdbaa 49.-daabc 50.-daacb
51.-dabac 52.-dabca 53.-dacab 54.- dacba 55.-dbaac 56.-dbaca 57.-dbcaa 58.-dcaab 59.-dcaba 60.-dcbaa
Ultimately Id like to use 32 harmonic slots with 32 letters for volume or maybe 10 letters for volume with 32 harmonic slots, is there an algorithm to this?
Can someone help me?!
Thank you!
PD vanilla on Windows 10 - coming from Mac
Hi lads and lasses,
I am an ex-mac user using pd 32 bit vanilla with zexy and gem libraries (manually installed).
I have recently changed to Windows 10 and in spite of efforts perusing forums and troubleshooting myself I can't seem to get the same kind of installation.
The problem (elaborated):
I want to install pd vanilla onto my windows 10 system, and then manually install zexy and gem libraries (and others in the future).
However, when I had my mac setup I had to install pd 32 bit (as gem was only fully functional on the 32 bit) and the library paths (folder locations for libraries, deken etc) were very different to what they are in windows. Currently I have no idea where to put files on my windows machine to make things work.
This is what it currently looks like at startup (on windows 10, pd vanilla, 0.47.1 64 bit) :
I am now faced with the following problems:
-I cannot find a 32 bit version of PD for my windows machine (so that I can run gem smoothly, assuming that is still the way it needs to be)
-I can't get deken to work, I have tried putting the deken plugin folder and master folder in various folders of program files but I keep getting error messages when I try and download a library (see yellow writing towards the bottom of the screenshot) when I go Help>Find Externals:
[that error followed the selection of a folder for the library to go:]
-Zexy and gem also won't load during startup with the startup flags (well that is because I can't find any place to save the library during the Find Externals command, but I have the startup flags in place for when deken does work).
So can anyone show me the error in my ways and better yet, the right path?
I need 32 bit pd for windows (I think for gem), the folder I need to put deken into , and the folders that I have to save the 'Get External' library downloads from.
Thanks in advance!
Freeverb~ with alternate filtering option available
There are deken packages for MacOSX, Windows and three Linux variants. The version is V1.2.2. Alternately you can download it from http://puredata.info/Members/fjkraan/software/freeverb~/1.2.2/
The Mac version shows up as:
freeverb~-v1.2.2-(Darwin-ppc-32)(Darwin-i386-32)(Darwin-X86_64-32)(Sources)-externals.tgz
install 32bit pd-extended on 64bit distro
@kalimerox I would just try? Pd extended (always 32 bit) installs fine in Windows 64bit, and I understand that MultiArch support in 64bit Debian runs 32 bit software natively.......
http://unix.stackexchange.com/questions/12956/how-do-i-run-32-bit-programs-on-a-64-bit-debian-ubuntu/47003#47003
David.
PD vanilla 0.42-5 - PortMidi midiout 'loses' (re-orders) bits
WinXP Pro SP3
Pd version 0.42-5
17-Jan-07 version of PortMidi
hey everyone,
I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found:
Patch (as attached:)
240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
|
midiout
And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions)
Problem
The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC
240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
and should convert have converted to HEX
F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7
instead, it comes out HEX
F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7
- with 3 wrong HEX pairs.
What happens
I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02
here's how it behaves in reverse engineering:
when i send DEC 0, 1, 2 or 3, it comes out HEX 0
when i send DEC 4, 5 6 or 7, it comes out HEX 1
see table:
DEC .. DEC -> HEX
00 .. 03 -> 00
04 .. 07 -> 01
08 .. 11 -> 02
12 .. 15 -> 03
16 .. 19 -> 04
20 .. 23 -> 05
24 .. 27 -> 06
28 .. 31 -> 07
32 .. 35 -> 08
36 .. 39 -> 09
40 .. 43 -> 0A
44 .. -> 0B
etc.
When you look at the BIN, it becomes obvious what's happening:
DEC (BIN) .. DEC (BIN) -> HEX (BIN)
00 ( 0) .. 03 ( 11) -> 00 ( 0)
04 ( 100) .. 07 ( 111) -> 01 ( 1)
08 ( 1000) .. 11 ( 1011) -> 02 ( 10)
12 ( 1100) .. 15 ( 1111) -> 03 ( 11)
16 (10000) .. 19 (10011) -> 04 ( 100)
20 (10100) .. 23 (10111) -> 05 ( 101)
.. two bits at the end are truncated.
It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message.
When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke.
Questions
- can anyone confirm this?
- is anyone currently maintaining PortMidi, so this could maybe get fixed?
thanks
groovelastig
http://www.pdpatchrepo.info/hurleur/sysex-conversion_vanilla.pd
Compiler flags for building an external in darwin
NAME=external~
CFLAGS = -std=c99 -DPD -O3 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -DMUUG_INTERPOLATE=1 -DMUUG_TILDE_TABLE_SIZE=512
UNIVERSAL=-arch i386 -arch ppc
DARWINCFLAGS = $(CFLAGS) -DDARWIN $(UNIVERSAL) -pedantic
DARWIN_LIBS=$(UNIVERSAL)
linux: $(NAME).pd_linux
.SUFFIXES: .pd_linux
.c.pd_linux:
gcc $(CFLAGS) -o $*.o -c $*.c
ld -export_dynamics -shared -o $*.pd_linux $*.o
strip --strip-unneeded $*.pd_linux
darwin: $(NAME).pd_darwin
.SUFFIXES: .pd_darwin
.c.pd_darwin:
cc $(DARWINCFLAGS) -o $*.o -c $*.c
cc -bundle -undefined suppress -flat_namespace $(DARWIN_LIBS) -o $*.pd_darwin $*.o
clean:
rm *.o
rm $(NAME).pd*
Set the variable in the first line (the name of the external)
for OS X run:
>make darwin
In this example it will compile the file external~.c to external~.o and than link external~.pd_darwin
Byte\[\] to Symbol
Hi everyone
My Max license dried out recently, so here I am in the PD forum. I've been patching for years in Max/MSP so PD feels very familiar. So far Im very impressed with everything.
MY PROBLEM:
Im sending a UDP message from a game engine (called Unity). The message is a string that have been encoded into a byte array using System.Text.ASCIIEncoding (.net/c#).
When I received this message in Max, the byte array was automatically converted into a string again. PD needs some help with this. How do I convert the byte array back into a string?
I get this:
48 32 49 54 46 53 32 48 46 49 48 56 54 51 49 51 32 48 46 49 57 53 56 57 50 57 32 48 46 49 56 48 56 52 54 57 32 45 48 46 48 55 49 53 54 50 54 56
Where I wanted somthing like this:
"theNerveNum 2 theTime 7612 theVelocity 0.76 theCenterDistance 0.23"
I use the "udpreceive" object for recieving the UDP message by the way.
Any help is much appriciated
~ce
Pd-extended on amd64
sorry for my last post, i must ahve been in a strange state of mind and gave wrong info, too, now i corrected it.
to compile pd-extended, you need to foolow those instructions:
http://puredata.info/docs/developer/Debian
later, those could be helpful too:
http://puredata.info/docs/developer/PdExtendedBuildSystem
http://puredata.info/docs/developer/
and at the end those inside: ../Pd-0.XX.X-extended/packages/linux_make/README where very usefull.
unfortunately there libdir loaders of 0.40 version won't compile,
pidip, OSCx and other externals won't compile neither, so I ended up hacking the Makefile in ../Pd-0.XX.X-extended/externals and ../Pd-0.XX.X-extended/packages.
At the end I had a succsesful installation, but as the compilation of libdir failed, all the externeals couldn't load, leaving me with a normal Pd / Gem / Pdp installation, basically. I tried to compile libdir against the former version "Pd-0.39.3-extended", and that worked. the compiled libdir.pd_linux however was not accepted by Pd-0.40.0-extended.
compiling Pd-0.39.3-extended's libdir.c against Pd-0.40.0-extended.spew out the same errors as before.
So, for me, it does not work...
I ended up again removing the whole thing and followed the intruction of myo.
(thanks myo),
followed this "howto install 32-bit .deb packages on 64-bit":
http://www.unixtutorial.org/2008/03/install-32-bit-deb-packages-on-64-bit/
and this one about how to install missing 32-bit libs using getlibs:
http://ubuntuforums.org/showthread.php?t=474790
some packeges couldn't be found by apt-get, so I had to get them here:
http://packages.ubuntu.com/
by typing the missing libs in the searchfield,
downloading the i386 versions,
opening those .deb packages with "Archive Manager" and browsing to data.tar.gz/./usr/lib/
selecting all the files and extracting them to /usr/lib32/
this worked pretty good.
pidip is working,
all externals are loaded,
thanks very much!
..wow, looks beautiful, and works very nice, thanks again
How do you timestretch?
umm...not sure if anyone's made a simple external to do that yet, but i'll tell you the way i was doing it:
*first, give up on sfplay~ ...you wanna write your audio files into arrays, and then use tabplay~
*the way in which i was "timestretching" was a bit weird, and the effect was a bit different to a normal timestretch, but it worked nonetheless....
what i did was to get the sample length in bytes from the output of the [soundfiler] object, and then divide that by 32 to give the lentgh of 1/32 part of the sample
tabplay~ can be triggered with byte offsets, so i used a metro and simple counter to increase the byte offset by 1/32 of a sample every click, and then return to zero after 32 clicks.
this worked really well for timestrethcing down, and sometimes worked ok for timestretching up, but it could get a bit stuttery.
recently though, i've been really getting into just changing the pitch to keep things looping. not sure why, it just sounds better to my ears when things get pitched funny.
Compiling for x86\_64
not really a useful reply, but i'm having the same difficulties. I'm guessing that something in the source code specifically is written for the 32 architecture. For instance on a 32 bit machine integers and floats are a specific size but in a 64 bit machine that size is different. Perhaps Puckette has some variables that are created on a low level so that he has specified the size to be that which is normally used in a 32 bit environment.
Hopefully when (if) I get the time i can take a look at the source code and see if I can find anything out. A cursory look at x_gui.c says that the line in quesiton reads "sprintf(buf, "d%x", (t_int)x);" . sprintf is this buffer writting mechanism...here he is writting something into the buffer and converting it to his own type (t_int), through explicit type casting, in the process.
He defines t_int in m_pd.h where he takes care of making sure all the precompiler junk is squared away.
"#ifdef __alpha__
typedef long t_int;
#else
typedef int t_int;
#endif"
Perhaps someone with experience in multiple architectures could help...or perhaps someone wants to bug a pd-extended developer or even Puckette himself.
My guess at a solution is to get the compiler to use a 32 bit word ("word" is the term for the size a variable takes up) and not a 64 bit word for all variables. (not quite sure if this is really possible though). You might also try compiling it on a 32 bit machine and copying the whole pd directory over to your 64 and giving that a shot.
Also you may want to change the makefile so that it points entirely to ../libs64/ or entirely to ../libs/