aboutsummaryrefslogtreecommitdiff
path: root/externals
diff options
context:
space:
mode:
Diffstat (limited to 'externals')
-rw-r--r--externals/build/doc/automata.txt178
-rw-r--r--externals/build/doc/examplescore.txt25
-rw-r--r--externals/debian/control10
-rw-r--r--externals/debian/pd-cyclone.copyright31
-rw-r--r--externals/debian/pd-cyclone.files2
-rw-r--r--externals/debian/pd-flext-ext.files7
-rwxr-xr-xexternals/debian/rules42
7 files changed, 281 insertions, 14 deletions
diff --git a/externals/build/doc/automata.txt b/externals/build/doc/automata.txt
new file mode 100644
index 00000000..afa5e9ee
--- /dev/null
+++ b/externals/build/doc/automata.txt
@@ -0,0 +1,178 @@
+[The following note originally appeared on the emusic-l mailing list. It is
+reprinted here with the author's permission]
+
+From xrjdm@FARSIDE.GSFC.NASA.GOV Wed Nov 23 11:26:39 1994
+Date: Tue, 4 Oct 1994 15:09:23 -0500
+From: Joe McMahon <xrjdm@FARSIDE.GSFC.NASA.GOV>
+Reply to: Electronic Music Discussion List <EMUSIC-L@AMERICAN.EDU>
+To: Multiple recipients of list EMUSIC-L <EMUSIC-L@AMERICAN.EDU>
+Subject: Automata: the long-awaited summary
+
+Back in August, I think, I promised to post a quick intro to cellular
+automata and how they can be used as a sound-generation tool. Since I'm
+going to take a couple of different sources and sum them up with little or
+no direct attribution, combined with my own opinions, I'll give everybody
+my references *first* so they can delete the article and draw their own
+conclusions if they so prefer.
+
+The primary reference that got me started on all this is one in the CMJ:
+Vol 14, No. 4, Winter 1990: "Digital Synthesis of Self-modifying Waveforms
+by Means of Cellular Automata" (Jacques Chareyon). Those who are already
+familiar with automata may just skip to that article and forget about the
+rest of this one.
+Note: the article gives a mail address for M. Chareyon, but he did not
+answer an inquiry about any available recordings using this technique in
+1990.
+
+So. Anyone still here? Good.
+
+Cellular automata are a mathematical concept first introduced in the late
+1940's. Generally speaking, a cellular automaton consists of a grid of
+cells. Each cell may take on any of a number of values - binary automata
+(cell on or cell off) are the most commonly studied. Each cell has a
+neighborhood, defined more simply as other cells which influence its state.
+The exact nature of this influence is defined by what are called transition
+rules. The cellular automaton starts off with some cells in any of the
+allowable states. for each "step" in the automaton's history, the
+neighborhood of every cell is checked, and the state of the cell is
+updated. All updates occur simultaneously.
+
+The transition rule must describe the resulting state of a cell for every
+possible configuration of other cells in the neighborhood. For large
+numbers of states, the amount of memory required to hold the transition
+rule becomes increasingly large, Therefore, some automata use what is known
+as a "totalistic" rule. These rules simply sum the values of the cells in
+the neighborhood and then assign a result on this basis. The resulting
+tables are far smaller.
+
+Many readers may already be familiar with John Horton Conway's game of
+"Life". This is a two-dimensional binary automaton with a totalistic rule.
+This makes for a very small rule set:
+
+ i) If fewer than two filled cells (cells with value 1) surround a cell,
+ it becomes empty next generation.
+ ii) If more than three filled cells surround a cell, it becomes empty
+ next generation.
+iii) If exactly three cells filled cells surround a cell, it becomes
+ filled on the next generation.
+
+This corresponds to a totalistic rule set with a total of 8(2-1)+1 or 9
+rules (one each for the sum values of 0 (no cells with a value) through 9
+(all cells with a value) ).If the transition rule were represented as a
+non-totalistic one, the rule set would need 2**8 or 256 entries. There are
+many interesting totalistic automata, so giving up detailed description of
+every nuance of the transitions to save memory space isn't a big sacrifice.
+
+Interesting as two dimensional automata are, they really aren't terribly
+useful for music making. There have been some experiments which have
+attempted to use a two-dimensional automaton to generate MIDI events -
+synthesis at the note level, using :
+
+Battista, T. and M. Giri, 1988. "Composizione Tramite Automi Cellulari."
+Atti del VII Cooloquio di Informatica Musicale. Rome, Italy: Edizione Arti
+Grafiche Ambrosini, pp. 181-182.
+
+Edgar, R. and J. Ryan, 1986. "LINA" Exhibition of the 1986 International
+Computer Music Conference, San Francisco: Computer Music Association.
+
+I have not heard any of the music from these efforts, so I certainly can't
+pass any judgement on them. For the purposes of this summary, we'll just
+look at one-dimensional automata. These use a linear array of cells, with
+the neighborhood generally being one or two cells on either side of each
+cell.
+(This is the type of automaton dealt with in M. Chareyon's article, which I
+will be paraphrasing broadly hereafter).
+
+M. Chareyon's automata are wavetables. A digitized signal is stored as a
+linear array of numbers in memory. A totalistic rule is used to determine a
+lookup value which indexes into an array containing the resulting value;
+this is saved into a second array. After the first array is completely
+processed, the roles of the two are swapped and the process is repeated.
+
+The limiting factor in this process is the number of bits of resolution
+being used to generate the sound. For a totalistic rule using a two-cell
+neighborhood and 12-bit individual samples, we have 3*(2*12) = 12288
+entries in the rule table. At 2 bytes each, this is 24K of storage. If we
+go to 16-bit sample resolution, we have 196608 entries at 2 bytes each for
+a total of 393216 bytes, or 384K.
+
+The key point of M. Charyeon's method is the use of small neighborhoods
+with large numbers of cellular states. Since the computation of the new
+wavetable is all table lookup, very complex transition rules can be
+precomputed and loaded into the tables, allowing the synthesis to
+essentially be a fast sum-and-lookup loop to calculate each new wavesample.
+>From the article, it appears that M. Chareyon was able to produce 2 or 3
+voices in realtime on a Mac II with a Digidesign Sound Accelerator board.
+It seems that it would probably be possible to use an AV Mac to do it
+without the board.
+
+This LASy (Linear Automaton Synthesis) method is closely related to the
+Karplus-Strong plucked-string algorithm, in that a wavesample is run
+through an algorithm which recirculates the samples to "self-modify" the
+wave. In fact, a judicious choice of table entries allows one to very
+simply simulate the K-S algoritm directly.
+
+So what are the sounds like? Some automata produce waveforms which quickly
+"ramp-up" to complex spectra and then drop off quickly. Others move to a
+steady state and then remain there. Yet others produce never-ending and
+unpredictable waveforms, whose harmonic content is constantly changing.
+
+Obviously enough, the original wavesample can be obtained mathematically,
+or by actual sampling and using LASy as a waveshaper. As M. Chareyon notes,
+a quick estimate of the number of possible automata for a 2-neighbor
+totalistic rule using a 256-entry wavetable with 12-bit entries is
+(2**12)**256 * (2**12)**(3*2**12) or about 10**4500 possible automata. Of
+course, many, many of these would not be suitable for music (e.g., the 4096
+automata in which all values go to one vlaue in one step, etc.); however,
+the number of musically useful automata is still likely to be an immense
+number.
+
+M. Chareyon provides a number of examples of ways to fill out the rule
+tables and a number of hints on creating wave tables - generally speaking,
+one can create a function which is used to compute the values to be placed
+into the table and then fill it so it can simply be loaded and used by the
+basic algorithm. His experience in using LASy is that he manages
+approximately 50% of the time to produce sounds with the desired
+characteristics, and that about 10% of the remaining time he gets
+unexpected but useful results which can be used as starting points for
+further exploration.
+
+Again, the important point is that the basic automaton uses wavesamples at
+full resolution, calculating a new wavesample for each step of the
+automaton; the next wavesample can be played while the new one is being
+calculated. Because of the large number of states, mathematical tools for
+the analysis of automata and the construction of automata with specifically
+desired qualities require too much storage and compute time to make them
+useful for LASy purposes.
+
+Again, much of this article is paraphrased from M. Chareyon's article; I
+take no credit for any of the work in this note. I'm just summarizing.
+
+The following other articles were referenced by M. Chareyon's article:
+
+Burks, A., ed. 1970. Essays on Cellular Automata. Champaign/Urbana, IL:
+University of Illinois Press.
+
+Chareyon, J. 1988a. "Sound Synthesis and Processing by Means of Linear
+Cellular Automata." Proceedings of the 1988 Internation Computer Music
+Conference. San Francisco: Computer Music Association.
+
+Chareyon, J. 1988b. "Wavetable come Automa Cellulare: una Nuova Tecnica di
+Sintesi." Atti del VII Colloquio di Informatica Musicale, Rome, Italy:
+Edizioni Arti Grafiche Ambrosini, pp. 174-177.
+
+Farmer, D., T. Toffoli, and S. Wolfram, eds. 1984. Cellular Automata.
+North-Holland Physics Publishing. [One of the definitive works on cellular
+automata - fairly heavy math, not a popular presentation - JM]
+
+Gardner, M. 1970. "The Fantastic Combinations of John Conway's New Solitare
+Game 'Life'". Scientific American 223(4) 120-123. [A good introduction to
+cellular automata, focusing on 'life' in specific. Useful intro if my
+1-paragraph summary of automata was confusing :) - JM]
+
+ --- Joe M.
+
+--
+"At the end of the hour, we'll have information on the sedatives used by
+the artists,,," (MST3K)
+
diff --git a/externals/build/doc/examplescore.txt b/externals/build/doc/examplescore.txt
new file mode 100644
index 00000000..78afd45e
--- /dev/null
+++ b/externals/build/doc/examplescore.txt
@@ -0,0 +1,25 @@
+60
+61
+62
+63
+64
+65
+66
+67
+68
+69
+70
+71
+72
+71
+70
+69
+68
+67
+66
+65
+64
+63
+62
+61
+60 \ No newline at end of file
diff --git a/externals/debian/control b/externals/debian/control
index f9768527..88f9460b 100644
--- a/externals/debian/control
+++ b/externals/debian/control
@@ -2,7 +2,7 @@ Source: pd-externals
Section: sound
Priority: optional
Maintainer: Guenter Geiger <geiger@debian.org>
-Build-Depends: debhelper (>> 3.0.0), pd, libsndobj-dev, libvorbis-dev, libogg-dev, libfluidsynth-dev, autoconf
+Build-Depends: debhelper (>> 3.0.0), pd, libquicktime-dev, libsndobj-dev, libvorbis-dev, libogg-dev, libfluidsynth-dev, autoconf
Standards-Version: 3.8.0
Package: pd-zexy
@@ -43,4 +43,10 @@ Depends: pd, ${shlibs:Depends}
Description: PD external collection
This is a collection of pd externals (plugins for the pure data software
synthesizer). The collection includes tons of well known pd externals.
-
+
+Package: pd-cyclone
+Architecture: any
+Depends: pd, ${shlibs:Depends}
+Description: PD cyclone extension
+ This extension to PD adds a MAX/MSP compatibility mode. MAX/MSP is
+ a trademark of Cycling74.
diff --git a/externals/debian/pd-cyclone.copyright b/externals/debian/pd-cyclone.copyright
new file mode 100644
index 00000000..34ee8399
--- /dev/null
+++ b/externals/debian/pd-cyclone.copyright
@@ -0,0 +1,31 @@
+This software is copyrighted by Miller Puckette and others. The following
+terms apply to all files associated with the software unless explicitly
+disclaimed in individual files.
+
+The authors hereby grant permission to use, copy, modify, distribute,
+and license this software and its documentation for any purpose, provided
+that existing copyright notices are retained in all copies and that this
+notice is included verbatim in any distributions. No written agreement,
+license, or royalty fee is required for any of the authorized uses.
+Modifications to this software may be copyrighted by their authors
+and need not follow the licensing terms described here, provided that
+the new terms are clearly indicated on the first page of each file where
+they apply.
+
+IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
+FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
+ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
+DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
+INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE
+IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE
+NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+MODIFICATIONS.
+
+RESTRICTED RIGHTS: Use, duplication or disclosure by the government
+is subject to the restrictions as set forth in subparagraph (c) (1) (ii)
+of the Rights in Technical Data and Computer Software Clause as DFARS
+252.227-7013 and FAR 52.227-19.
diff --git a/externals/debian/pd-cyclone.files b/externals/debian/pd-cyclone.files
new file mode 100644
index 00000000..518e160b
--- /dev/null
+++ b/externals/debian/pd-cyclone.files
@@ -0,0 +1,2 @@
+usr/lib/pd/externs/cyclone/
+usr/lib/pd/doc/cyclone
diff --git a/externals/debian/pd-flext-ext.files b/externals/debian/pd-flext-ext.files
new file mode 100644
index 00000000..46a5b909
--- /dev/null
+++ b/externals/debian/pd-flext-ext.files
@@ -0,0 +1,7 @@
+/usr/lib/pd/extra/shabby*
+/usr/lib/pd/extra/shaffy*
+/usr/lib/pd/extra/syncgrain~.pd_linux
+/usr/lib/pd/extra/fluid*
+/usr/lib/pd/doc/5.reference/help-fluid.pd
+/usr/lib/pd/doc/5.reference/help-shaffy~.pd
+/usr/lib/pd/doc/5.reference/help-shabby~.pd
diff --git a/externals/debian/rules b/externals/debian/rules
index b107bb06..8f1d11be 100755
--- a/externals/debian/rules
+++ b/externals/debian/rules
@@ -40,17 +40,17 @@ build-stamp: configure-stamp
(cd build/linux; $(MAKE))
# Build zexy
-
+
(cd zexy/src; $(MAKE) -f makefile.linux LINCLUDE="-I ../../build/include")
# Build flext
-
+
(cd grill/flext; $(MAKE) -f makefile.pd-linux PDPATH=../../build/include)
# Flext externals
#
- (cd footils; make PD_DIR=../../build/include \
+ -(cd footils; make PD_DIR=../../build/include \
FLEXTPATH=../../grill/flext/pd-linux \
FLEXTINC=../../grill/flext/source \
FLUIDLIB=" -lfluidsynth")
@@ -61,10 +61,15 @@ build-stamp: configure-stamp
(cd OSCx/OSC; $(MAKE))
# build PDP
-
+
(cd pdp;autoconf;./configure;$(MAKE))
(cd pdp/scaf/;autoconf;./configure;$(MAKE))
+ # build cyclone
+ -mkdir miXed/bin
+ (cd miXed/cyclone; make PD_DIR='../../build/include')
+
+
touch build-stamp
clean:
@@ -80,7 +85,7 @@ clean:
-rm `find . -name "*.obj"`
# fix up wrong permissions
-
+
chmod 644 `find . -name "*.h"`
chmod 644 `find . -name "*.c"`
chmod 644 `find . -name "*.pd"`
@@ -91,8 +96,8 @@ clean:
(cd zexy/src; $(MAKE) -f makefile.linux clean)
(cd grill/flext; $(MAKE) -f makefile.pd-linux clean)
-
- (cd footils; make clean)
+
+ -(cd footils; make clean)
(cd OSCx/libOSC;$(MAKE) clean)
(cd OSCx/OSC; $(MAKE) pd_linux_clean)
@@ -105,7 +110,10 @@ clean:
config.status \
autom4te.cache \
Makefile.config)
-
+# Clean cyclone
+#
+ (cd miXed/cyclone; make clean)
+ -rm miXed/bin/cyclist
dh_clean
@@ -118,30 +126,40 @@ install: build
# Add here commands to install the package into debian/pd-externals.
(cd build/linux; $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp)
(rm -r `find $(CURDIR)/debian/tmp/ -name CVS`)
-
+
(cd zexy/src; $(MAKE) -f makefile.linux install DESTDIR=$(CURDIR)/debian/tmp \
INSTALL_PREFIX=/usr/ \
PDLIBDIR=lib/pd )
(cd grill/flext; $(MAKE) -f makefile.pd-linux install INSTDIR=$(CURDIR)/debian/tmp/usr/lib/pd/flext)
- (cd footils; make FLEXTPATH=../../grill/flext/pd-linux \
+# Install footils ... this is quite messy still, have to find a better solution
+
+ -(cd footils; make -k FLEXTPATH=../../grill/flext/pd-linux \
FLEXTINC=../../grill/flext/source \
DESTDIR=$(CURDIR)/debian/tmp INSTPATH=$(CURDIR)/debian/tmp/usr/lib/pd/extra install)
install -m 644 footils/fluid/pd/fluid.pd $(CURDIR)/debian/tmp/usr/lib/pd/doc/5.reference/help-fluid.pd
install -m 644 footils/shabby/shaffy~-help.pd $(CURDIR)/debian/tmp/usr/lib/pd/doc/5.reference/help-shaffy~.pd
install -m 644 footils/shabby/shabby~.pd_linux $(CURDIR)/debian/tmp/usr/lib/pd/doc/5.reference/help-shabby~.pd
+ -rm $(CURDIR)/debian/tmp/usr/lib/pd/extra/fiiwu*
+
-
# Install OSC
install OSCx/OSC/OSC.pd_linux $(CURDIR)/debian/tmp/usr/lib/pd/extra
install -m 644 OSCx/doc/*.pd $(CURDIR)/debian/tmp/usr/lib/pd/doc/5.reference
# install pdp (needs /usr/lib/extern)
-
+
mkdir $(CURDIR)/debian/tmp/usr/lib/pd/externs
(cd pdp;make prefix=$(CURDIR)/debian/tmp/usr/ install)
+ # Install cyclone
+
+ mkdir $(CURDIR)/debian/tmp/usr/lib/pd/externs/cyclone
+ install $(CURDIR)/miXed/bin/*.pd_linux $(CURDIR)/debian/tmp/usr/lib/pd/externs/cyclone/
+ mkdir $(CURDIR)/debian/tmp/usr/lib/pd/doc/cyclone
+ install -m 644 $(CURDIR)/miXed/test/cyclone/*.pd $(CURDIR)/debian/tmp/usr/lib/pd/doc/cyclone
+
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.