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.
[muse] -- float array that acts like a musical scale
Creates music scales using simple lists or by sending new pitches to individual notes. The more creation arguments there are, the more inlets there will be. It sends a frequency value through the 1st outlet and the unaltered midi value through the 2nd outlet.
- [muse 40 4 7]
- Sending 0, 1, 2 returns 40, 44, 47 respectively.
- The scale cycles through higher and lower octaves
- 3, 4, 5 returns 52, 56, 59
- -1, -2, -3 returns 35, 32, 28
functions:
- [list | l | d | x | i ..(
- Takes a list of numbers and maps the values to the array.
- Any non-numeric values are skipped over.
- They're basically all the same function, with the differences being in their offsets and/or whether it should change the size of the scale implicitly based on list size.
-- i is an implicit list, which changes the size of the scale based on the number of arguments specified.
-- x is an explicit list, which means that it doesn't change the scale size because it's leaving that up to the user to change explicitly. This message is also good for changing the root note.
-- list or l is the default list, and whether it interprets lists implicitly or explicitly is based on whether the toggle "exp" is set to 1 or 0. By default, lists are interpreted implicitly.
-- d has an offset of 1. It's basically a short form of [list d ...( or, a list that skips the root note. Like a normal list, it also adheres to the "exp" toggle to determine whether it is implicit or explicit.
- [exp 1|0(
- sets a boolean to determine whether or not scale size is implied in the size of lists sent.
- if exp equals 1, scale size will not change, unless the list is preceded by i.
- if exp equals 0, scale size will change, unless the list is preceded by x.
- [n $1(
- sets the size of the scale.
- the scale by default, with no creation arguments, is only 2 float values. This amount grows based on how many arguments are specified. but the array also resizes itself automatically to twice its original size whenever a size requested goes over the current maximum range.
- the same doubling effect applies to lists with more arguments than the maximum scale size.
-- [muse 40 2 4 5 7 9 11] has 7 floats worth of bytes reserved for the scale.
-- upon receiving [n 16(, since 16 is greater than (7 x 2), scale is resized to hold 16 floats.
-- upon receiving [n 17(, scale is resized to hold 32 floats. This doesn't mean the scale uses all 32 notes, but the space is now reserved if you ever decide to increase the scale size later.
- sets the size of the scale.
- [set $2 $1(
- scale is assigned the value $1 at index $2.
-- [set 6 11( set the 6th interval to 11.
- scale is assigned the value $1 at index $2.
- [ref $1(
- sets the reference pitch of middle A.
-- default value is 440.
- sets the reference pitch of middle A.
- [tet $1(
- assign the number of tones in an octave.
-- tones refer to how large a semi-tone needs to be in order to evenly disperse an octave into a specific amount of distinct pitches.
- assign the number of tones in an octave.
- [oct $1(
- assign the number of notes in an octave.
-- notes refer to the number of semi-tones that the scale should jump when going to the next or previous octave.
- assign the number of notes in an octave.
- [octet $1( / [ot $1(
- assigns # of notes and # of tones simultaneously
- [peek label(
- prints the current scale.
- a label is optional.
- [ptr label(
- prints the current size of the float pointer that your scale uses. It isn't necessarily the same size as the scale itself.
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
Zexy compiling os x
ok, here's the deal.
i'm trying to install zexy 2.1. i'm using pd 0.41-1, on a macbook pro os x.4.11 with xcode.
i've put the zexy-2.1 folder in ~/Library/Application Support/Pd
i've changed the terminal directory to the src folder within this directory, and executed "./configure" successfully.
the problem comes in the next step. the linux install instructions say type "make" followed by "make install".
once i've run "make", it comes up with the following:
zexy.h:38:18: error: m_pd.h: No such file or directory
and from what i've read, m_pd.h is quite important. the terminal also displays lots of other error messages, mainly starting with:
a2l.c:XX:
i've also tried this command, which is stated in the install instructions:
"make -f makefile.darwin"
but it comes up with this:
make: makefile.darwin: No such file or directory
make: *** No rule to make target `makefile.darwin'. Stop.
this makes sense, as "makefile.darwin" is not included in the src directory (or anywhere in "zexy-2.1" for that matter)
i'm new to all this compiling malarkey, so any help on this matter would be greatly appreciated.
cheers
dom
The History about a little video launcher patch...
hi, this is my beginning: i need a "thing" who launches two videos and two audios (pre-recorded, aleatory selected) of a list, in the moment that i make a noise (enoug noise) in a microphone, for that i make this simple patch:
----cut from here----
#N canvas 92 55 825 609 12;
#X obj 85 5 gemhead;
#X obj 345 161 pix_film;
#X msg 488 98 auto \$1;
#X obj 488 78 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 825 212 gemwin;
#X msg 805 105 create;
#X msg 892 182 destroy;
#X msg 848 149 1;
#X msg 853 178 0;
#X msg 753 81 border 0;
#X msg 710 155 dimen 2048 768;
#X obj 85 161 pix_film;
#X obj 85 218 pix_texture;
#X msg 192 92 auto \$1;
#X obj 192 71 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X msg 192 126 colorspace RGBA;
#X msg 488 120 colorspace RGBA;
#X obj 345 435 rectangle 0 0;
#X floatatom 419 328 5 0 0 0 - - -;
#X obj 394 405 /;
#X floatatom 465 328 5 0 0 0 - - -;
#X obj 444 405 /;
#X obj 374 290 unpack 0 0 0;
#X obj 85 260 translateXYZ;
#X obj 85 431 rectangle 0 0;
#X floatatom 159 327 5 0 0 0 - - -;
#X obj 134 401 /;
#X floatatom 205 326 5 0 0 0 - - -;
#X obj 184 400 /;
#X obj 114 284 unpack 0 0 0;
#X msg 153 372 60;
#X msg 203 373 50;
#X obj 345 216 pix_texture;
#X obj 345 262 translateXYZ;
#X msg 413 376 60;
#X msg 463 377 50;
#X msg 192 223 -5.5;
#X msg 318 100 open lib/video\$1.mov;
#X msg 8 102 open lib/video\$1.mov;
#X msg 488 225 10.8;
#X obj 1146 4 loadbang;
#X msg 488 45 1;
#X msg 192 46 1;
#X msg 488 167 0;
#X msg 192 174 0;
#X msg 682 447 open lib/audio\$1n.wav;
#X obj 993 124 adc~ 2;
#X obj 995 279 s sincro;
#X obj 957 61 s aleatorio_1;
#X obj 1047 91 s aleatorio_2;
#X obj 144 195 s fin_video;
#X obj 404 190 s fin_video;
#X obj 682 331 r aleatorio_1;
#X obj 957 5 r sincro;
#X obj 1047 4 r sincro;
#X obj 1146 39 s inicio;
#X obj 1024 192 r inicio;
#X obj 753 7 r inicio;
#X obj 805 34 delay 5;
#X obj 848 74 delay 5;
#X msg 936 441 open lib/audio\$1n.wav;
#X obj 853 356 r sincro;
#X obj 681 527 dac~ 3;
#X obj 997 527 dac~ 4;
#X obj 936 335 r aleatorio_2;
#X obj 682 483 readsf~ 2 221000;
#X obj 936 476 readsf~ 2 221000;
#X obj 318 14 r aleatorio_2;
#X obj 192 12 r inicio;
#X obj 134 348 r inicio;
#X obj 488 10 r inicio;
#X obj 401 349 r inicio;
#X obj 717 390 delay 5;
#X obj 971 389 delay 5;
#X obj 599 345 r sincro;
#X msg 599 403 1;
#X obj 624 16 r inicio;
#X msg 624 46 \; pd dsp 1;
#X obj 501 142 r fin_video;
#X obj 221 148 r fin_video;
#X obj 927 266 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X msg 853 417 1;
#X obj 8 51 r aleatorio_1;
#X obj 994 156 hip~ 5;
#X obj 995 246 threshold~;
#X obj 957 32 random 4;
#X obj 1047 31 random 4;
#X msg 1024 220 set 0.6 1000 0 100;
#X obj 717 361 r fin_video;
#X obj 971 360 r fin_video;
#X obj 599 373 delay 6;
#X obj 853 390 delay 6;
#X obj 682 416 float;
#X obj 936 415 float;
#X msg 732 117 cursor 0;
#X connect 0 0 11 0;
#X connect 0 0 1 0;
#X connect 1 0 32 0;
#X connect 1 1 22 0;
#X connect 1 2 51 0;
#X connect 2 0 1 0;
#X connect 3 0 2 0;
#X connect 5 0 4 0;
#X connect 6 0 4 0;
#X connect 7 0 4 0;
#X connect 8 0 4 0;
#X connect 9 0 4 0;
#X connect 10 0 4 0;
#X connect 11 0 12 0;
#X connect 11 1 29 0;
#X connect 11 2 50 0;
#X connect 12 0 23 0;
#X connect 13 0 11 0;
#X connect 14 0 13 0;
#X connect 15 0 11 0;
#X connect 16 0 1 0;
#X connect 18 0 19 0;
#X connect 19 0 17 1;
#X connect 20 0 21 0;
#X connect 21 0 17 2;
#X connect 22 1 18 0;
#X connect 22 2 20 0;
#X connect 23 0 24 0;
#X connect 25 0 26 0;
#X connect 26 0 24 1;
#X connect 27 0 28 0;
#X connect 28 0 24 2;
#X connect 29 1 25 0;
#X connect 29 2 27 0;
#X connect 30 0 26 1;
#X connect 31 0 28 1;
#X connect 32 0 33 0;
#X connect 33 0 17 0;
#X connect 34 0 19 1;
#X connect 35 0 21 1;
#X connect 36 0 23 1;
#X connect 37 0 1 0;
#X connect 38 0 11 0;
#X connect 39 0 33 1;
#X connect 40 0 55 0;
#X connect 41 0 3 0;
#X connect 42 0 14 0;
#X connect 43 0 1 1;
#X connect 44 0 11 1;
#X connect 45 0 65 0;
#X connect 46 0 83 0;
#X connect 52 0 92 0;
#X connect 53 0 85 0;
#X connect 54 0 86 0;
#X connect 56 0 87 0;
#X connect 57 0 9 0;
#X connect 57 0 10 0;
#X connect 57 0 58 0;
#X connect 57 0 94 0;
#X connect 58 0 5 0;
#X connect 58 0 59 0;
#X connect 59 0 7 0;
#X connect 60 0 66 0;
#X connect 61 0 91 0;
#X connect 64 0 93 0;
#X connect 65 0 62 0;
#X connect 66 1 63 0;
#X connect 67 0 37 0;
#X connect 68 0 42 0;
#X connect 68 0 15 0;
#X connect 68 0 44 0;
#X connect 68 0 36 0;
#X connect 69 0 26 0;
#X connect 69 0 30 0;
#X connect 69 0 28 0;
#X connect 69 0 31 0;
#X connect 70 0 41 0;
#X connect 70 0 16 0;
#X connect 70 0 43 0;
#X connect 70 0 39 0;
#X connect 71 0 34 0;
#X connect 71 0 35 0;
#X connect 71 0 19 0;
#X connect 71 0 21 0;
#X connect 72 0 92 0;
#X connect 73 0 93 0;
#X connect 74 0 90 0;
#X connect 75 0 65 0;
#X connect 76 0 77 0;
#X connect 78 0 43 0;
#X connect 79 0 44 0;
#X connect 81 0 66 0;
#X connect 82 0 38 0;
#X connect 83 0 84 0;
#X connect 84 0 47 0;
#X connect 84 0 80 0;
#X connect 85 0 48 0;
#X connect 86 0 49 0;
#X connect 87 0 84 0;
#X connect 88 0 72 0;
#X connect 88 0 90 0;
#X connect 89 0 73 0;
#X connect 89 0 91 0;
#X connect 90 0 75 0;
#X connect 91 0 81 0;
#X connect 92 0 45 0;
#X connect 93 0 60 0;
#X connect 94 0 4 0;
----cut to here---
i'm sorry for space wasted, but is the 4:02 (...of course!),
the "thing" works, i have the video and audio libs in the apropiate site (they are 5 .mov files and 5 .wav, not very heavy content), but at the third clap in front of the mic it hangs, allways on the third, and a bit later a beatiful death blue screen (yes, i'm windozed, linux don't have drivers for my presonus firestation), i test it in two partitions (same machine), any ideas? Thanks for reading, interest, and.. for all, best regards.
jano
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/