Similar to [pack ] and [unpack ] but instead of the default atom type being a float, the default type is anything.

Also comes with a new creation arg 'a' for anything. Numbers and unrecognized types will also default to anything.

For strict type checking, use f(loat), s(ymbol), and p(ointer).
The pak object will also store unrecognized types as symbols and interpret 'b' as a 'bang' symbol.

You can send lists to any of the additional pak inlets and it will store the list values with the inlet as the starting point. For example, sending the message [foo bar 3 baz( to the 2nd inlet of [pak 1 2 3 4] would result in the list: 1 foo bar 3

The example includes another object called [x ], which is a kind of trigger object that dehusks lists that consist of only 1 element when you use 'a' or nothing for creation args. For pd-vanilla users, the example also requires zexy's [demux].

You can also use "." to skip inlets and assign only specific ones.
For example, sending the message [. . 123( would assign 123 to the 3rd inlet and leave the first two values the same as they were. You can send these messages to any inlet.
The skip arg feature only applies to list and anything type messages, so if you really want to, you can still assign a single period to an inlet by sending it as a symbol.

There are two more objects [@pak] / [@unpak] - reverse pak/unpak, which output the lists in reverse order.

Strict-type error messages are muted by default and to unmute them, you need to send [mute 0( to the 1st inlet. The number sent to mute acts as a bit mask for the inlets, so when a bit is turned on, the associated inlet will output error messages.

pak-unpak.zip

@Enkerli Hi there.

Actually when you trigger a note your program sends out 7 notes:

• 1 - the note you actually played.

• 2 - the 3 notes coming out of the [+ ] objects, which are the note you played (in the hot inlet) summed to the last value you put into the right inlet (cold one).

• 3 - the 3 notes coming out of the [+ ] objects after the bang, which are the last value you put into the left inlet (the note you played) summed to the new value they received into the right inlet after [sel].

This is because you are using the note you played as a trigger for 3 different things, that are [noteout], [+ ]s and [mod 12]. You should avoid multiple connection when not needed and should be aware that every "number" you send acts both like a number and a bang. Also, be aware of the difference between cold and hot inlets, the first are just "memory", you put something in there and will remain there until the output is triggered, Usually this happens when something goes into the hot inlet, it may be a number, a symbol or a simple bang. Use the [trigger] object to force a bang into the hot inlet when you input something into the cold one.
I modified your patch and commented each solution, give it a look and everything will be clear

chorder-solution.pd

They're like [mtof] and [ftom], but now the objects accept 2 parameters:

• the reference pitch for middle A (default value is 440)
• the number of tones (default value is 12)

So let's say you want your reference pitch to be 432, considered by some to be a more mellow frequency, you would write:

• [ntof 432]

and to split an octave into just 8 distinct tones instead of the most conventional 12, you'd write:

• [ntof 432 8]

You can change these values after instantiation by using messages:

• [ref $1(
  • changes the reference pitch
• [tet $1(
  • changes the number of tones (in equal temperament)

It also comes with two counter objects: [cupq], and [cupqb]

[cupq] has three inlets:

• left inlet decrements
• right inlet increments
• middle inlet changes the step size.

[cupqb] is similar, but it includes an atom box, allowing you to slide the current count. It has two inlets:

• first inlet receives [+ $1( and [- $1( messages
• second inlet controls the step size.

[cupq] and [cupqb] are .pd files, so there's actually more you can do with them than what I've specified here.

These files are also on my github page under pd-externals.

EDIT: My musical scale object [muse] now also takes advantage of the ref and tet messages. Its help file allows you to play around with these features. The files have now also been added to the zip.

ntof-fton.zip

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.

• [set $2 $1(
  • scale is assigned the value $1 at index $2.
    -- [set 6 11( set the 6th interval to 11.

• [ref $1(
  • sets the reference pitch of middle A.
    -- default value is 440.

• [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.

• [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.

• [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.

muse-chrd.zip

first it's important to know, that an operation with control objects like [+] have a "hot" inlet (left) and a "cold" inlet (right). the operation is only triggered at the hot inlet, so if you want to trigger an operation by the cold inlet too, you have to send a bang to the hot inlet, when the value at the cold inlet changes. you can do this with the [trigger] or [t] object. have a look at the attached patch. [t b f] sends first the float value at it's inlet to it's right outlet, then a bang to it's left outlet.is there a reason why you used the [expr] objects, since you could also use the common [+] and [>=] objects?
however, have a look at the patch and check out, if suits your needs.

http://www.pdpatchrepo.info/hurleur/ad_generator_with_lfo.pd

[tim@vosto src]$ uname -a
Linux vosto 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[tim@vosto src]$ cd /pd/src
[tim@vosto src]$ ./configure
bash: ./configure: No such file or directory
[tim@vosto src]$ sudo autoconf

[tim@vosto src]$ sudo ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
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 a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... gcc -E
checking for an ANSI C-conforming const... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /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 for pid_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking bstring.h usability... no
checking bstring.h presence... no
checking for bstring.h... no
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking whether gcc needs -traditional... no
checking return type of signal handlers... void
checking for vprintf... yes
checking for _doprnt... no
checking for gettimeofday... yes
checking for select... yes
checking for socket... yes
checking for strerror... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for dlopen in -ldl... yes
checking for sin in -lffm... no
checking for sin in -lm... yes
checking for pthread_create in -lpthread... yes
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking for main in -ltcl85... no
checking for main in -ltcl8.5... yes
checking for main in -ltk85... no
checking for main in -ltk8.5... yes
.................... alsa= yes
checking for snd_pcm_info in -lasound... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
./configure: line 5767: syntax error near unexpected token `SINF,'
./configure: line 5767: `AST_EXT_LIB_CHECK(SINF, m, sinf)'

I can't solve this compilation error. Can anyone help?
I found a similar problem here: http://bbs.archlinux.org/viewtopic.php?id=86440
Unfortunately the planet CCRMA packages are quite fare behind the fedora releases, otherwise I'd use them.

Greetings all,

I have just posted a collection of student patches for an interaction design course I was teaching at Emily Carr University of Art and Design. I hope that the patches will be useful to people playing around with Pure Data in a learning environment, installation artwork and other uses.

The link is: http://bit.ly/8OtDAq
or: http://www.sfu.ca/~leonardp/VideoGameAudio/main.htm#patches

The patches include multi-area motion detection, colour tracking, live audio looping, live video looping, collision detection, real-time video effects, real-time audio effects, 3D object manipulation and more...

Cheers,
Leonard

http://www.VideoGameAudio.com

Pure Data Interaction Design Patches

These are projects from the Emily Carr University of Art and Design DIVA 202 Interaction Design course for Spring 2010 term. All projects use Pure Data Extended and run on Mac OS X. They could likely be modified with small changes to run on other platforms as well. The focus was on education so the patches are sometimes "works in progress" technically but should be quite useful for others learning about PD and interaction design.

NOTE: This page may move, please link from: http://www.VideoGameAudio.com for correct location.

Instructor: Leonard J. Paul
Students: Ben, Christine, Collin, Euginia, Gabriel K, Gabriel P, Gokce, Huan, Jing, Katy, Nasrin, Quinton, Tony and Sandy

GabrielK-AsteroidTracker - An entire game based on motion tracking. This is a simple arcade-style game in which the user must navigate the spaceship through a field of oncoming asteroids. The user controls the spaceship by moving a specifically coloured object in front of the camera.
Features: Motion tracking, collision detection, texture mapping, real-time music synthesis, game logic

GabrielP-DogHead - Maps your face from the webcam onto different dog's bodies in real-time with an interactive audio loop jammer. Fun!
Features: Colour tracking, audio loop jammer, real-time webcam texture mapping

Euginia-DanceMix - Live audio loop playback of four separate channels. Loop selection is random for first two channels and sequenced for last two channels. Slow volume muting of channels allows for crossfading. Tempo-based video crossfading.
Features: Four channel live loop jammer (extended from Hardoff's ma4u patch), beat-based video cross-cutting

Huan-CarDance - Rotates 3D object based on the audio output level so that it looks like it's dancing to the music.
Features: 3D object display, 3d line synthesis, live audio looper

Ben-VideoGameWiiMix - Randomly remixes classic video game footage and music together. Uses the wiimote to trigger new video by DarwiinRemote and OSC messages.
Features: Wiimote control, OSC, tempo-based video crossmixing, music loop remixing and effects

Christine-eMotionAudio - Mixes together video with recorded sounds and music depending on the amount of motion in the webcam. Intensity level of music increases and speed of video playback increases with more motion.
Features: Adaptive music branching, motion blur, blob size motion detection, video mixing

Collin-LouderCars - Videos of cars respond to audio input level.
Features: Video switching, audio input level detection.

Gokce-AVmixer - Live remixing of video and audio loops.
Features: video remixing, live audio looper

Jing-LadyGaga-ing - Remixes video from Lady Gaga's videos with video effects and music effects.
Features: Video warping, video stuttering, live audio looper, audio effects

KatyC_Bunnies - Triggers video and audio using multi-area motion detection. There are three areas on each side to control the video and audio loop selections. Video and audio loops are loaded from directories.
Features: Multi-area motion detection, audio loop directory loader, video loop directory loader

Nasrin-AnimationMixer - Hand animation videos are superimposed over the webcam image and chosen by multi-area motion sensing. Audio loop playback is randomly chosen with each new video.
Features: Multi-area motion sensing, audio loop directory loader

Quintons-AmericaRedux - Videos are remixed in response to live audio loop playback. Some audio effects are mirrored with corresponding video effects.
Features: Real-time video effects, live audio looper

Tony-MusicGame - A music game where the player needs to find how to piece together the music segments triggered by multi-area motion detection on a webcam.
Features: Multi-area motion detection, audio loop directory loader

Sandy-Exerciser - An exercise game where you move to the motions of the video above the webcam video. Stutter effects on video and live audio looper.
Features: Video stutter effect, real-time webcam video effects

no, that's not a miracle:

the right inlet of the [+] object stores the incoming value until the the operations gets started by an incoming event at the left inlet. if you connect the number box first to the right inlet and then to the left inlet, the following happens:
the number box shows 10, then the second inlet of the [+] object receives the value first and stores it, but it will not trigger an operation. immediately the left inlet receives the value (10) - this event triggers the operation (in this case an addition) and results in an output value of 20 (10 on the right + 10 on the left, then processed addition)
if you first connect to the left inlet of [+] and then the right inlet, the left inlet receives the data and imediately triggers the opereation - so it receives a 10 and triggers an addition with the last stored value at right input:
if you tweaked the number box from 0 to 10, the last stored input at the right inlet has to be a 9, so the result is 19. if you tweaked it down from a higher number, the last stored value must have been an 11 so the result is 21.

edit: i'm sorry, i must have been to tired, when i typed that shit yesterday.... i changed some things now! hope you understand what i mean...

There is a very interesting help topic called 03.connection.pd in the puredata doc. I can't understand why the numbers add up the wrong way. Let me pick up a concrete situation for better understanding:

the input number box is set to '33', wires are crossed in the '+' object (rig the left inlet first, right inlet last). if I scroll up the value to '34', then accroding to that tutorial, and as proved by experience, the right inlet of the '+' object does not receive the value '34', only the left inlet does, so the outlet of '+' returns 34+33=67. But if wires are 'uncrossed' (rig right inlet first, left inlet last), then what ? ok I suppose the right inlet (so called 'cold' inlet) receives data first, but then why does the left inlet receive data too ? It's a miracle in that case, the outlet returns 34+34=68.

If the author of 03.connection.pd is around I would be extremely grateful if he could explain me this curiosity in detail ... I'm beginning in puredata, I need to use it for my phD, and if that kind of misbehaviour happens for a simple addition then it's gonna happen for more complicated things. I can deal with a technical explanation, in fact I would love one, please.

cheers
legus

for some reason, the list of error messages became even longer......

mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
[makesymbol] part of zexy-2.2.3 (compiled: Feb 25 2009)
Copyright (l) 1999-2008 IOhannes m zmölnig, forum::für::umläute & IEM
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
[demultiplex] part of zexy-2.2.3 (compiled: Feb 25 2009)
Copyright (l) 1999-2008 IOhannes m zmölnig, forum::für::umläute & IEM
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
wahwah~: an audio wahwah, version 0.1 (ydegoyon@free.fr)
expr, expr~, fexpr~ version 0.4 under GNU General Public License
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
error: inlet: expected '' but got 'symbol'
... you might be able to track this down from the Find menu.
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'

i'd really love to check out, what you have build there!