Archive

Never store "derived" files in version control. Check in only source files, makefiles, etc.; the results of the build process (.o files, executable files, Java .class files, etc.) should not be under version control.

## Leading minus signs

If a filename begins with "-", like "-foo", then SVN commands will think you're supplying a command-line option when you're really trying to give the name of the file.

Solution: refer to the file as ./-foo, as in

svn mv ./-foo +foo

## Umlauts

SVN fails in an ugly way when you try to check out a file with an umlaut in its name.

## Version numbers

Each external should include its version number as described [cnmat:node/272|here]. Packages of patches that we release with the old new Max downloads page can have their version and other information in the same format in a separate "infosource.txt" file.

##

Every patch or [cnmat:node/272|textual source code file] should contain a comment listing the names of the authors and the year(s) it was written.

Software developed by CNMAT students, faculty, and staff almost always belongs to the University.

Each patch or external should have a help patch listing all of its features. The help patch should show how the object would be used in context and designed for easy cut and paste.

For a file named something.pat, something.mxb, or something.mxt, its help patch should be named something.help.pat

A generic help file can be found in the repository in /MMJ-Depot/baseline/support/

While not every patch implements all of these messages, these are some very common and desirable messages for a patch to understand:

• /gain Controls the Linear Amplitude of the signal output. Should accept an optional second argument to change to a specific amplitude over a number of milliseconds.
  

The central website for all versions of Subversion is here: http://subversion.tigris.org/project_packages.html
But keep reading---you probably want to follow one of the links later on this page.

SVN stores the entire history of not just each individual file, but also of how they were arranged into a hierarchical directory structure. When you decide to move a file (or subdirectory) to a new place in the tree structure, SVN can move that file's history along with it. (That means that when somebody wonders what this "new" file is doing there, they'll be able to trace its origin back to the old days before you made this move, or a complete history of its names, locations, and commit logs for changes.)

You are free to work in your working directory, which tends to create files, many of which should never touch the repository.

When you want a file to go into the repository, you need a working directory containing the subdirectory that the file will go into. Put the new file in that subdirectory (by saving, moving or copying) of your working directory.

svn add _filename_

What if you change your mind about adding a new file?

# If you already committed the new file

Delete it from the repository:

> svn rm _whoopsie.mistake_
> svn commit

# If you didn't commit the file but already did "svn add"

> svn revert

# If you haven't done "svn add"

Just delete it. Or leave it there for now; it's not bothering svn to have it there.

You're going to delete the whole directory containing the problem. Choose a reasonably small directory that completely contains the problem.

First, make sure everything else of value in the directory (especially including the file(s) you're having trouble with) is committed to the repository or backed up somewhere else on your computer.

There are two important aspects to the programming style of the CNMAT MMJ Depot. First, it should be relatively easy for developers to add new patches and second, it should invite users to copy and paste elements into their own patches. To facilitate these, the number of required elements are minimal. Specifically:

Using the aka.mouse objects (only available on Macintosh)

USB HID Game Controllers are available including a "two controller's-in-one"

Morning Lecture
--------------
* RF sensors
* Wireless interfaces and reliability

Guest @10am
--
John Lazzaro: anatomy of digital cameras, Reliable wireless MIDI

Laboratory
----
* Max Radio Drum, Marimba Lumina,
* Projects
* Q and A

Night Class at 6pm: special guest: David Z, Max 5?
----

Morning Lecture
--------------
* Spatial Audio
* Design Patterns: One source/speaker, heterogeneous speaker distribution
* Cameras: occlusion, lighting, image processing

Guest@10am
---------
Ali Momeni

Laboratory
-------
* field trip to see the 120-channel speaker array
*vbap, jitter, multitouch Tactex

Morning Lecture
------
* Musical and Image Processes
* Map the Time variable
* Interpolation and dimensionality reduction and expansion
* Design Pattern: make and explore design spaces, embrace randomness and indeterminacy
* Resonances
* Introduction to "Standard" Controllers: tablets, game controllers, fader banks, MIDI keyboards, multitouch (maybe?)

Guest @10am
------

Morning Lecture
--------
* More OSC tools
* Design Patterns: wrappers
* Review of sensor integration systems: Bitwacker, CUI, Arduino, Make Controller, Rimas Box, New Rimas Box
* Introduction to HID devices and MIDI
* Parameter Naming and The unit interval
* Sensor signal conditioning:
* Scaling, Clamping, Calibration, Mapping, Fusion, Debouncing, Filtering, Interpolation,

Morning Lecture
--
* Welcome to CNMAT
* Introductions
* Overview of the Week:
* Moving from:
* contact sensors (mostly charge-flow based), e.g. many touch, switches,
* near-field sensors (mostly e-field based). e.g. capacitive proximity, inertial
* to far-field and very distant sensors, e.g. cameras, sattelites
* And:
* mono sound output
* multichannel output

The "CNMAT" svn repository runs from feldman.cnmat.berkeley.edu, the G5 in the media studio. It contains a large quantity of MaxMSP software and other materials. It has no web-view. See "Using Subversion", etc.

Rimas manages a collection of svn repositories on cage.cnmat.berkeley.edu. It has a web front-end at [https://cage.cnmat.berkeley.edu/viewsvn].