ModWiki - User contributions [en]

Polygome

2012-08-13T22:23:33Z

Ground state:

== Video Tutorials ==

[http://www.youtube.com/watch?v=W1O8c8vLVMY&list=UUffhayZv3WqTz2ZaEkIwR3w&index=3&feature=plcp b99 Tutorial for Polygome with OhmRGB]

=='''Overview'''==

[[File:Polygome_pic.png]]

== Original Docs ==

[http://docs.monome.org/doku.php?id=app:polygome monome patch]

Polygome isn't an easy concept...but I think its one of the best patches Stretta has made.

This port behaves mostly the same as his, but lives in Live and remembers its states. And you can run multiples.

The right hand buttons (scene launch) select which
mode the grid is in.
Mode 1 is play. The key pressed is the root of the sequence that is selected.
Mode 2 is record. You record the sequence by pressing up to 16 cells on the grid.
Mode 3 programs velocity for each step.
Mode 4 programs duration for each step.
The bottom row of Mode 4 allows for turning off or on each step.

You can send MIDI to polygome and change the the scale that is assigned.

The top right and left corner of the grid is the hold button.

Try the gomeizer if you're stumped...its instant gratification (after a wait of a few seconds to randomize everything)....

Then off to google, to find out whats really going on ;)

'''IMPORTANT TIP: Live's transport ''must'' be running in order for polygome to do ''anything''.'''

[[Category:Mods]]

Category:Mods

2012-07-19T19:37:33Z

Ground state: creation

List of pages for Monomodular Mods

Help

2012-07-19T19:36:23Z

Ground state: add category

[[File:Mod_help_pic.png]]

The Monomodular framework has two things at its core that allow it to operate:

===The Monomodular Python Scripts===

These reside in Live's Application bundle on MacOSX, or in the Program Folder on Windows. They are capable of communicating with other loaded Monomodular compliant control scripts internally via Python. They also contain individual client components that communicate via MXDCore to m4l patches, and the mod.js javascript implementation (see below). As of b993, they also contain a MonoLinkClient, which is a new class that is capable of sending and receiving OSC in monomeserial or serialosc communication protocols to emulate a monome directly, as well as publish its connection information via Bonjour.

===The mod.js Javascript Object===

[[File:Modjs bpatcher.png]]

The mod.js is a javascript object that connects to the Live API Control Surface controls inside of the Monomodular script in order to communicate directly with the other controller scripts that it has access to. The javascript itself lives inside of a bpatcher, with some other objects that are necessary for it to connect and disconnect when Live changes in and out of edit mode, as well as a menu object for assigning the Python Client class that it's connected to. It should remain in this bpatcher to work properly, and the best way to use it in a new patch is to install it from Max's clippings.

The mod object automatically attempts to connect to a Python client whenever it is installed in an active Live set. However, its behaviour while in edit mode is somewhat different (and at times unpredictable, so its best to play by the rules with it). Don't have more than one mod instance open in a patch. Also, don't have more than mod instance open in the editor at once. Its possible to work this way, but can cause connection issues and posssible crashes of the editor.

Recently (b993), the mod.js has been corrected to maintain its connection state when switching between edit modes in Live, and to persist after saving a patch wherein it is connected to a client.

====Inlets====
The mod object, in its connected state, is capable of sending data to its Client instance, and of receiving data from the physical controllers that are connected to it. Each individual inlet on the top of the bpatcher object accepts a different kind of data:

1. The leftmost inlet accepts grid states. This data should be sent in the form (x, y, value), where x and y are values between 0 and 15, and value is a number between 0 and 127. It is intended to be used with a [matrixctrl], but this is only a convenience. You can send data from anything, as long as its formatted correctly.

2. The next inlet accepts key states. This data should be sent in the form (key, value), where key is a value between 0 and 7, and value is a number between 0 and 127.

3. The third inlet accepts swing value. It should be sent as a single integer value between 0 and 100. This inlet is here so that you can send the current swing value out to the Monomodular switchboard, and have it transmitted to another 'global swing' patch, like the Swing16 mod. It will probably be removed in b994.

4. This inlet accepts three different general functions. Among these are 'autoselect', 'offset', and 'color_map'. This outlet, also, will probably disappear by b994.

5. The last outlet accepts data that will be sent to a connected Code controller. Whilst the Code is supported by Monomodular, its architecture is different and therefore required a different set of commands. They will be detailed later in the section directly covering Code functions.

There are quite a few other commands that can be sent to the mod object, however they are inlet-independent (i.e. you can send them in any inlet). The convention of having different inlets for general data is merely a convenience, and any of the functions sent to them can be effected in the same manner by prefixing a set of arguments by their function name.
For example, sending the message "0 0 1" in the first inlet of the mod object will have the same effect
as sending a message "grid 0 0 1" in any of the inlets: both will light the top left button of their corresponding Client.

Additional commands available for input:

'''send_color_map''': This allows a properly formatted color map to be sent to Monomodular, which contains specific color mappings for different kinds of supported controllers. For instance, you can create two different color maps, one for a monochrome device, and another for an RGB device, so that things can be displayed in more sensible ways depending on the controller being used. See below for more info on this.

'''set_report_offset''': This function tells Monomodular to send the current offset value back to the mod anytime that it changes.

'''clear''': This is functionally the same as calling "batch_grid_all 0", and will set all values of the grid (16x16) to 0.

'''batch''': This sets a set of cells to the same value. It requires a second argument:
grid: The statement "batch grid 2" will set all cells on the 16x16 grid to the value of 2.
row: The statement "batch row 0 1" will set an entire top row on the grid to the value of 1.
column: The statemnt "batch column 15 0" will turn off an entire right column of the grid.

'''mask''': This allows masking of a cell without actually changing its Client's stored value. For instance, if you've sent a "grid 0 0 1" call to the client, it has stored the top left cell's value as 1. If you navigate to a different client from the controller, or change navigation positions, and then return to view that cell, it will be relit to a value of 1. However, the "mask" function allows the user to send a new value to that cell without changing its stored value. This is useful for overlays or running status indicators that are not meant to be stored values, but merely flash for an instant and then go away as soon as the condition changes.

The "mask" function also requires a second argument:
grid will mask a single cell, for example, "mask grid 0 0 2" will light the top left cell with the value of 2.
To turn off the mask, we would call "mask grid 0 0 -1".
You an also mask columns or rows by calling "mask column x value" or "mask row y value".
If you don't turn off the mask, it will revert to the stored value the next time the Python Client updates.

'''send_hotline''': this is a new function in b993, and basically allows calling internal functionality of another connected mod.js by routing it through the Monomodular switchboard. If it does not find a corresponding function in the target mod.js, it sends the arguments out of a uniquely named send in the target mod's patcher [r ---hotline]. As an example:
To call the 'clear' function in another connected mod (say, the one in mod slot three), we could send a command:
"send_hotline 3 clear"
Or, to set the swing of all connected mods to 0%, we could send the command:
"send_hotline all swing 50"
Or, to send a message to the [r ---hotline] object of mod 2 (if it has one), we could send the command:
"send_hotline blah 34"
This last one would cause the [r ---hotline] receiver to spit out the message 'blah 34'.

This is hardly useful yet for me, but I have devious plans for it in the future ;)

'''exclusive''': this is an extension of the hotline() function, and has the same effect, except that it will send the arguments out of other mod connected patchers through a uniquely named receive object with the name of the first argument to the exclusive function.
Sending the mod bpatcher the arguments "exclusive blah sammy 35" will cause the message "sammy 35" to be distributed to any
connected mods and sent out a [r ---blah] object in those mods (if one exists).

====Outlets====
The outlets transmit data from a Monomodular controller when it is connected to the Client belonging to the mod:

1. The leftmost outlet will send out grid press data in the format: x, y, value. x and y are numbers between 0 and 15, and value is always either 0 or 1.

2. The second outlet will send out key press data in the format: key, value. key is a number between 0 and 7, and value is always either 0 or 1.

3. The third outlet will send out the current channel selection of the client. It will be a number between 0 and 15.

4. The fourth outlet will send out 'wheel' data from a connected Code controller. Again, the format of this data will be discussed in the section specific to the Code.

In addition to these outlets, you can also create a [receive] object prefixed with '---' and the function's name, and it will receive the same data.
For instance, the same data will emit from the first outlet as it will from a receive object named [r ---grid] when you press a grid button on the connected
controller and it is in modmode with your client selected on that controller.

Other commands that can be received through uniquely named receive objects include the following:

[r ---toggle_mute]: this object will send out the current mute status of the controller when holding alt and pressing the 6th key.

[r ---refresh]: this object will send out a bang any time the Monomodular Switchboard connects to the mod patch (e.g. when first loading the mod or when changing its client number).

[r ---alt]: this object will send the current value of the alt button any time it is pressed or released.

[r ---offset]: when "set_report_offset" is set to 1, this object will report any changes to the currently selected client's offset values.

[r ---hotline]: this object will receive calls initiated from other mods that are connected to Monomodular. See above.

====Creating a mod instance from scratch====

If you've installed Monomodular using its installer (from version b993 and forward), it should have been placed there automatically. If not, you can place the files manually:

The file "mod_b993.js" should be somewhere in your Max search path. The installer places it inside of the "aumhaa_blocks" folder.

The file "mod_b933_abstract.maxpat" should be in the same place (or somewhere in your Max search path).

The file "mod_b993.maxpatch" should be in your "/Max5.xx/patches/clippings" folder.

Once these three files are in their proper places, restart Max. If you open up a new m4l patch and right click a blank space, you should be presented with a menu. Towards the bottom of that menu is a submenu called clippings. You can paste a new instance of the mod object from here.

[[File:Clipping_pic.png]]

Once you've pasted the new instance of the mod object inside a patcher, you'll need to save the patch, delete it from your Live set, and then reload it in order for it to work right.

Once you've reloaded the fresh patch, it should automatically connect to a Client. You should not make changes to the client settings if you are editing the patch. I've tried to sandbox it so that things don't go wrong while in edit mode, but doing this requires that the Client number be locked, and this is far from fool-proof. Its best just not to mess with it ;)

[[Category:Mods]]

Clipchopper

2012-07-19T19:36:11Z

Ground state: add category

=='''Overview'''==

[[File:Clipchop_pic.png]]

I barely touched this. There are lots of error messages I've noticed in the Max window. I'll investigate when time/inclination allows. I suspect that it has nothing to do with anything I've done.

I've made very few changes except necessary to port over to the mod world (which was close to nothing, in this instance, since this was already built for m4l).

It begs the question why there aren't more mod-supported plugins? Well, I guess maybe there will be soon....

[http://docs.monome.org/doku.php?id=app:live_clip_chopper Original Page]

[[Category:Mods]]

Xor

2012-07-19T19:36:04Z

Ground state: add category

=='''Overview'''==

[[File:xor_pic.png]]

A quick port....pretty self explanatory if you check out the developer's page.

I've changed very little except for the UI and some things necessary to recall values in m4l and maintain discreet send/receive channels so that you can run multiple instances.

Keys 1 & 2 alternate between 'value' and 'link' modes.

Original patch by tehn, who has gifted us with more more than just some wonderful hardware inventions.

[http://docs.monome.org/doku.php?id=app:xor Original Page]

[[Category:Mods]]

Grainstorm

2012-07-19T19:35:55Z

Ground state: add category

[[File:Grainstorm_pic.png]]

This is a quick port of Stretta's Grainstorm for monome and arc over to the Codec script....you can pretty much do everything with a single controller.

The first four encoders on the right take the place of the arc 4. You can choose the focused voice by the row buttons on the far right. The bottom column buttons allow storing and recalling of presets for the focused voice.

Keys 1-4 allow copying of the current Maxloop buffers over to each Grainstorm voice (depending upon which one is focused). Key 5 allows for access to some miscellaneous controls at the bottom of the patch window that wouldn't fit easily.

This patch shows some of the capabilities of the Codec script off, as well as some possibilities of the new 'hotline' functions built into the b993 mod script. This is how it is able to connect to the loopmaster and send its buffer's name, which loopmaster then forwards to the appropriate Maxloop patch with instructions to fill the buffer with the Maxloop's current loop buffer.

I made very few changes to the original patch besides the obvious UI restructuring. I had to scale down all of the vectors for Arc, since there are 64 leds on it and only 14 on the code. Otherwise, I mainly just removed things from view, even though they are still there in the patch (e.g. the vst~ instance for aux output). I'll probably come back to this later...I've barely played with it yet, so surely some changes are in order.

Here's the original page:

[http://docs.monome.org/doku.php?id=app:grainstorm Grainstorm]

Many thanks, as usual, to Matthew Davidson for sharing his wonderful ideas with the world :)

[[Category:Mods]]

Boiingg

2012-07-19T19:35:46Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=5aAfRYEQcJc&list=UUffhayZv3WqTz2ZaEkIwR3w&index=4&feature=plcp b99 Tutorial for Boiingg with OhmRGB]

=='''Overview'''==

[[File:boinngg_pic.png]]

Choose grid type by pressing one of the first four key buttons (shift bottom row or bottom row while shift-locked).

Choose timing with second four key buttons.

Timing multiplier speeds up timing.

Store and recall presets by holding down ALT button.

== Original Docs ==

[http://docs.monome.org/doku.php?id=app:boiingg monome site]

[[Category:Mods]]

Sment

2012-07-19T19:35:38Z

Ground state: add category

=='''Overview'''==

[[File:Sment_pic.png]]

[http://stretta.blogspot.com/2009/12/sment.html Stretta Page for Sment]

I ported this one early in b99's existence just as an excercise to see how long the porting procedure would take.

I think I spent about a whole 20 minutes on this one.

a

[[Category:Mods]]

Tintinnabulome

2012-07-19T19:35:21Z

Ground state: add category

=='''Overview'''==

[[File:tintin_pic.png]]

Tintinabulome is a collaboration of several different guys, I think. Here's some links to the original monome forum posts:

[http://post.monome.org/comments.php?DiscussionID=2959&page=1#Item_0| Original Posts]

I've done my best to get this working as expected as a mod port....it seems to have had some problems with it before I got to it, sorry.

a

[[Category:Mods]]

Polygome

2012-07-19T19:35:11Z

Ground state: add category

PressCafe

2012-07-19T19:35:02Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=H34J1Nehgvk&list=UUffhayZv3WqTz2ZaEkIwR3w&index=6&feature=plcp b99 Tutorial for PressCafe with OhmRGB]

=='''Overview'''==

[[File:presscafe_pic.png]]

[[Category:Mods]]

Tr256

2012-07-19T19:32:17Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=q4d6MriD6y4&list=UUffhayZv3WqTz2ZaEkIwR3w&index=5&feature=plcp b99 Tutorial for TR256 with OhmRGB]

=='''Overview'''==

[[File:tr256_pic.png]]

== Original Patch Info ==

TR256 for Monomodular b992.

TR256 is one of Stretta's patches I took a liking to when I first started working with monome patches. I've changed it quite a bit since he released it.

Mode buttons (Scene buttons on the Launcpad/APC/iPad):
1-4 sets velocity. Its scaled between the low and high setting on the GUI.
5-7 sets the timing rate: 1/4 to 1/16. (shift 1-3 on APC)
8 turns on triplet. (shift 4 on APC)

Their are 16 programs.
The top row selects which one to edit.
The second row selects which one is playing.
The third row is the running status and allows the user to change the beginning and length of the program. If you hold down the end of the sequence and press a step to the right, it will change the starting point.
To copy from one program to another:
Press and hold the edit of the one you wish to copy, and then the play of the destination program.
To clear:
Press and hold the edit of the program to clear, then press one of the velocity mode buttons (1-4).
To enter record mode:
Press both edit and play at the same time.
TR256 will record into the current pattern whatever is routed to it via MIDI that matches its output assignment. The timing will be quantized to the current timing setting.
When restart is enabled, the loop will restart at the beginning of the beat after a timing change has occured.

[[Category:Mods]]

Loopmaster

2012-07-19T19:32:06Z

Ground state: add category

== Summary ==

LoopMaster is a Mod that controls up to 4 individual [[MaxLooper]]s that are grouped in a rack on a seperate audio channel. LoopMaster must be placed on a MIDI capable track. It is possible to control the loopers by assignment of its controls in Live's MIDI Map, by triggering its functions from MIDI (from live input or a session clip), and by connecting a pedal device to a MonOhm through its expansion port (Block to come shortly, if anyone tells me they need it). You can see a picture of the pedal that is used to control it on the bottom of the page, along with the LCD screen app designed into the Lemur AumPad/256 scripts to display feedback information from the loopers.

The LoopMaster's controls are mostly just redundant versions of the MaxLooper's controls, with a few exceptions.

[[File:Loopmaster.jpg]]

== Loop Selector ==

This drop-down allows you to select an individual loop to act upon, or all at once. This is usually controlled by the pedal, but can be accessed from the grid as well. '''ALL''' is useful for making global settings like inertia, quantization, and latency compensation. However, some of the settings reflected in the GUI may not be an accurate reflection of the Loopers, since it can only report one at a time.

== Invert ==

This control changes the polarity of the expression pedal connected to the Loop Pedal. Since I'm the only one that has one, I'm pretty sure this is immaterial to anyone else at this point.

== Port and Host ==

If you are using the Lemur version of AumPad/256, there is an LCD built into the first page. Turn it on with the little round button on the Lemur, and make sure that you've entered your iPad's host address correctly. It will reflect all the changes in the LoopMaster/MaxLoopers. The correct port is already assigned @ 8000, if you have something on this port you will also have to edit the Lemur patch (or change the port setting on your other application).

== Mod Number ==

The plugin transmits and receives from Monomodular. Each quadrant on the 256 represents one of the four loopers. The bottom row turns quant on/off and sets the quantization amount. The Center swirly bit shows the loop position, and allows retriggering by pressing the keys on the time-line square. Pressing the middle of this square will hit Reverse. The first 5 buttons on the seventh row are: Undo, Overdub, Record, Mute, Clear. The far right column, top 5 buttons are 2x, 1x, stop, -1x, -2x from the top. The next column over controls inertia amount. You can select the loop that belongs to the quadrant by hitting the lowest right button (I think...its down there somewhere, I never use it really).

This is all going to change soon....I'm going to limit the whole grid to 64, and allow selection of loop# with the bottom right 4 buttons. Probably also the timing keys will become 4x 2x 1x .5x 0. Another grid screen will allow different retriggering or something....I dunno, its late.

== 010212 rev11 ==

These are the implements of the LoopMaster plugin, which is designed to control 4 instances of MaxLooper. The pedal selects loop number, reverses, clears, overdubs, records, and mutes for individual loops or all at once. It can advance back or forward between loops, select a specific loop, or select all loops. It also has a quarter inch stereo jack on the rear which allows you to connect an expression pedal to control feedback amount for the selected loop (here I have it hooked up to a slightly modified volume pedal, just because it ''feels better'').

The pedal is designed to offer a bunch of controls in a small amount of space. There are seven buttons, at staggered levels so that the top four can be hit to select loops without touching the bottom three that are used for controlling the loops. I was tired of trying to carry the FCB1010 around, and I'm very glad to be rid of it.

The top four select individual loops.

The right top two (together) increase the selected loop number by one, while the left two decrease it.

The center two top buttons select all loops.

The left bottom is Overdub, the center bottom is Loop, and the right bottom is Mute.

There are other combination functions as well (left top w/Mute is reverse, right top w/Overdub is clear, center two top w/Record is Undo).

The pedal can be configured for sequence launching in my setup with another controller (so that it can trigger Looper MIDI sequences from Lives session). Still working on this part though, as I would really like to use scripting for this ala ClyphX.

[[File:PedalPic.jpg]]

This is a pic of the new LCD app, which will work for either a Lemur setup or a window on your computer that's running Live and Monomodular. The upper window shows the Looper GUI, and the lower shows the LCD for the OhmRGB that's currently connected to it. The plan is to have that same panel work for all the other controllers that I support with Monomodular.

[[File:LoopmasterLCD.jpg]]

Basically, the top portion functions as feedback for the four [[MaxLooper]]s connected to it. The current selected loop is highlighted in white. The current loop position is indicated by the dial. The state of the looper is indicated by the button in the middle. The amount of feedback is displayed below each dial.

Eventually, these LCD objects will become controls as well.

[[Category:Mods]]

Monotes

2012-07-19T19:31:56Z

Ground state: add category

Monotes for Monomodular b992.

[[File:Monotes_pic.png]]

A simple patch to convert keypresses on the grid to note information, and send it to different locations depending on your whim.
Assign notes, velocities, and durations either by scale, or freely using the custom editor.
Notes can be sent directly the output of the plugin (which in turn can be directed specifically in the MIDI sub-window), or can be sent directly to a specific channel of a Nome or lh_midi object.

[[Category:Mods]]

Aumboids

2012-07-19T19:31:46Z

Ground state: add category

=='''Overview'''==

[[File:Aumboids_pic.png]]

Aumboids is a mod that uses positional information to generate notes and controller data based on distance relationships between agents in a flock.

Most of the processes were culled from javascripting that is included in the standard installation of MaxMSP (I had to dig a bit to find them, though). I've heavily modified the whole thing.

There are 12 agents. Each agent of the flock has its own root note assignment, as well as tonal relationships that it exhibits depending on what is near it.

There is one dedicated flock 'Leader', which may be changed dynamically by holding down '''ALT''' and selecting one of the top row of grid keys, or by selecting a new tab on the bottom of the plugin's GUI.

The leader is always attracted to a position on the grid which represents the gravitational center. This position may be changed by pressing the button that you wish to be the new center of gravity.

The leader of the flock is indicated by a different color. Its closest 3 agents will be indicated by another color. Every time the closest neighbor changes, a new note will be played based upon the assignments for the fundamental tone of the leader and the modal relationships to his nearest neighbors.

[[File:Aumboids_ex1.png]]|[[File:Aumboids_ex2.png]]

In addition, each agent sends out a controller value based on its distance from the leader, and this changes on every frame (beat). Output of each agents controller can be muted with the bottom buttons on the GUI or by holding '''ALT''' and pressing one of the bottom 8 left buttons on the modGrid.

[[Category:Mods]]

Life

2012-07-19T19:31:37Z

Ground state: add category

Life for Monomodular b992.

Life was an attempt to make some use out of the jit.conway external back in my early days of playing with mt control surfaces. I've cleaned it up a bit for final release and have translated everything into Javascript so I could decipher what the hell I was thinking when I made it 2 years ago.

Basically, it makes no sense at all. Its mainly a randomization sequencer, and is most usefull when combined with some other engine for timing purposes. However, it can be fun in its own way.

The second to bottom row of the 256 turns each of the 16 steps off or on.

The bottom row:

1st button solos the current plane.

2nd - 11th selects preset maps (or stores them when alt is pressed).

12th button clears the current plane.

13-16 button turns on/off each plane (ignored when in solo mode).

Keys 1-4 select the current plane.

Keys 5-8 select timing in the usual manner (when set to internal).

[[File:Life ex1.png]]

[[Category:Mods]]

Binary

2012-07-19T19:31:23Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=an0dz5PD7ho&list=UUffhayZv3WqTz2ZaEkIwR3w&index=1&feature=plcp b992 Release Tutorial]

=='''Overview'''==

[[File:Binary_pick.png]]

Binary for Monomodular.

Binary is a variable speed programmable sequencer originally built for use with Livid's Code. It grew out of early experimentations with the Code and some lofty ideas. You can expect some future changes.

Its best to watch the video tutorial in order to figure out what's going on, but here is a list of the basic controls:

Code.

Each dial contains a variable length/speed sequence. Select a sequence by pressing the dial, and the white LED below it will light.

The 8 steps nearest to the playhead (left) are shown on the bottom buttons. Active steps are lit. You can assign steps by pressing buttons. You can scrub the playhead by pushing the selected dial and turning it. You can change the speed of the sequence by turning the dial. The current position of each sequence is always indicated by it's dial's LED strip.

By pushing and holding a dial, then pushing another dial, you may lock the second sequence's speed to the first's.

The active status of each sequence is indicated by the green light on the dial's LED strip. You can change its active status by pressing the top right button while the sequence is selected.

Additionally, the second button on the right changes whether the selected sequence is quantized. Quantize state is displayed by whether a selected sequence's white LED is blinking (quantized) or solid (free).

The third button on the right changes the sensitivity of the dials.

The fourth button on the right converts the bottom row of dials to mirror the plugin GUI controls (also available via Live Device).

Grid.

The Grid has five modes, used for programming the sequences or playing them back. Each sequence can be up to 64 steps in length, and each step can contain up to 8 simultaneous notes, can be turned on or off, and has independent velocity (but all notes played in that step share a common velocity).

The Keys are the same for both Grid and Codec (Keys are shift-bottom row buttons on Codec):

1 - Step Mode. (turn steps on or off)
2 - Length Mode. (1 - 64 steps)
3 - Note Mode. (turn notes on or off)
4 - Velocity Mode. (change velocity of each step)
5 - Active Mode. (turn activity on or off)
6 - Toggle Play Mode. (press and hold vs. toggle for Active Mode, and while 'Play Mode' is on, pressing a dial is momentary active instead of selection; also turns off ability to change speed by turning a the sequence's dial)
7 - Hold to select sequence (selected lit on grid, flashing if locked)
8 - Toggle selected sequence's quantize status.

In addition, you may store and recall up to 32 presets by pressing ALT on the Grid.

This plugin is very useful as a timing engine for other Mod plugs, and has been tailored for this purpose.

[[Category:Mods]]

Endcoders

2012-07-19T19:31:07Z

Ground state: add category

[[File:endcoders_pic.png]]

EndCoders for Everything b992.

OK, maybe not everything. But a bunch of things.

Basic idea: You have 8 mappable knobs. Each knob is capable of controlling 24 different parameters at once, each with its own breakpoint curve. You can store eight banks of presets containing these breakpoint curves, and whether or not each curve is active or not.

If you have a Livid Code, its pretty simple to get around (you'll need Monomodular and the new Codec scripts):

Press the top row of knobs to select which master knob you wish to edit (the LED below it should light up). All of its parameters are instantly brought up on the remaining rows of dials, along with the current values of those parameters. If the green light is on, that means the dial is 'active', and linked to the breakpoint curve of its parent knob. You can toggle the active status by pressing that knob.

To choose what a parameter dial is linked to, simply select that parameter in Live (by clicking on it; it should show a darker area around it when its selected), and press the dial while holding down the third button from the top on the left side. If successfully linked, the LED below it will light up.

You can now turn the top knob to any desired position, then turn the parameter to where you want it to be at the knobs position (either by turning the parameters dial, or by changing it in Live), and take a snapshot of that value on the parameters breakpoint curve by holding down the second row left button and pressing down on the dial (it is often useful to turn the parameter dial's active status off while doing this stuff).

You can capture all the parameter values at once by holding down the second row button and pushing the knob that belongs to that parameter group (the top row of knobs).

You can clear the breakpoint graph by holding down the top row button and pressing the parameter dial.

You can clear ALL a knobs breakpoint graphs by holding down the top row button and pressing the knob.

You can change the dial speed by toggling the fourth row button. It will be lit while fast is on.

You can open up the editor for a knob by holding down the third row button and pressing one of the top knobs corresponding.

You can store presets by holding shift and pressing one of the bottom column buttons, and recall them by pressing the same buttons without shift held.

I've tried to make the plugin as versatile as possible for those without a Livid Code. You can still do all the important stuff, but you'll have to go about it differently. The currently selected knob is available in the GUI, and the small buttons on the top right of each graph allow selection of the parameter for the graph (left one) and change of the graphs active state for each preset (right one).

You can only have one breakpoint active per Live parameter, but of course you can have different combinations by storing the active state in different presets. If you select a parameter that is already chosen and active on a new graph, the old one will automatically be deactivated when you select the new one.

Of course, you can also just use the entire thing without the breakpoints (by deactivating everything) to store parameters in banks that you can get to easily by pressing the top row of buttons.

[[Category:Mods]]

Plinko

2012-07-19T19:30:46Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=6CP7t_sfpBg&list=UUffhayZv3WqTz2ZaEkIwR3w&index=10&feature=plcp Very early on....]

[http://www.youtube.com/watch?v=o5RwIkh5hDw&list=UUffhayZv3WqTz2ZaEkIwR3w&index=9&feature=plcp A little more coherent].

=='''Overview'''==

[[File:plinko_pic.png]]

Plinko is a generative plugin built to be freely editable in realtime. See below for some attempts at explaining how it works (its, uh....well, its rather complicated).

Basically, each cell on the modGrid represents a 'node'. Each node represents the possibility of something happening. Particles are generated at the beginning of each loop cycle (if 'Loop' is turned on) from start-nodes on the grid. A start node can be created by holding down a node button and pressing the first '''KEY'''.

When a particle is generated, it will begin travelling in a certain direction on the grid. For every new node it enters, several possible outcomes could occur.

[[File:Plinko flowchart.png]]

There are four planes of possibility for every node. Each plane is calculated in turn, starting with plane 1. To view the assignments for each node's plane, press one of the first four '''KEY'''s while nothing else is being held.

The settings for a node will be displayed on the modGrid while holding down that node's button. Depending on the orientation of the node selected, the screen may be reversed so that scale, note, and probability are on the right side of the grid instead of the left.

[[File:Plinko_assignments.png]]|[[File:Plinko ex1.png]]

=='''KEY''' Assignments==

In addition to these basic functions, while holding down a node's button and pressing one of the '''KEY'''s, the following changes can be made:

'''KEY 1''': This will enable/disable the node as a starting node (the color of the node will change while it is being held to indicate its status).

'''KEY 2''': This will cause the node to become a 'wormhole'. While continuing to hold down the node button after pressing '''KEY 2''', the next cell pressed on the modGrid will become the wormhole's destination.

'''KEY 3''': This will copy the current plane's settings to all the other planes of the node being held.

'''KEY 4''': This will clear the current plane's settings, setting probability, scale, and note settings to 0, and removing any wormholes or directions.

It is useful when programming on multiple planes to use the node+'''KEY 4''' combination to clear the current plane's settings, and then the node+'''KEY 3''' combination to copy those cleared settings to all of the other planes of the current node.

==Presets==

While holding '''ALT''', it is possible to store and recall preset nodal arrangements. To store a preset, hold '''ALT''' and press one of the lower 4 rows of modGrid buttons. Available slots for storage (i.e. those with no preset data stored in them) will be lit.

The user can recall one of the stored presets by holding '''ALT''' and selecting one of the top 4 rows of lit buttons.

As soon as a preset is stored by pressing one of the buttons on the bottom 4 rows, it will become lighted and available for recall on the corresponding button from the top 4 rows.

==Assignments==

Pressing the "assign notes" button will expose a floating window which will allow user assignments of MIDI Notes to different grid positions in the main Plinko editor screen. Each column represents one 'octave' of the assignment matrix. The assignments can be based on standard modal scales, or completely custom mappings.

Pressing the "Open Custom Assignment Editor" button will reveal the custom assignments grid. These assignments correspond to the 64 possible combinations of the two assignment buttons on the editor. Each column only applies to its corresponding column in the "assign notes" screen (so a column is only active if its corresponding column in the parent editor is assigned to "custom").

In addition, there is now a new window available, the [[Script_Editor| "Script Editor"]] window. Please see the corresponding section for more information about this:

[[Script_Editor| The Script Editor Window]]

== Original readme contained in early versions of this mod ==

(This is the original text document that was included with the plugin when I first released it. It is probably still somewhat helpful, and I think all these directions still apply to the current version)

Plinko/Monodal beta 0.8

The concept: Plinko is a generative grid-based sequencer. Points of potential (particles) are placed on the a, moving in a certain direction. For every new grid-square they enter, there are five user-assignable outcomes that are possible, based on the result of a random number generated each turn. Each active node may alter a particles path or fire a note when the particle passes over it. A user assignable scale may be assigned to each "octave", or a cusomized midi map may be assigned (on a per octave basis). Each octave may also be assigned to output to a generic plugin output (the monomod channel for the device), or to any specific nomeout. In this way, Plinko can feed up to eight different instruments at once.

Each square on the launchpad/grid represents a "node".

A node is either active or passive depending upon whether it has been assigned "attributes".
Each node is a potential "loopstart" point.
Each node has 4 "planes".
Each plane has independent "direction", "note", "octave", "probability", and "wormhole" attributes.

By holding down a grid key, one can assign multiple directions to a node by pressing the keys adjacent to the pressd node. The far left or right columns, depending upon the area of the grid pressed (fi the node is on the right part of the grid, the columns will be on the left, and vice versa), represent (from left to right): octave, note, probability.

The four monomod "mode" buttons have the following effects:

When no node is pressed, they select which plane is active.

When a node is pressed:

1 - activates (or deactivates) the node as a loopstart point when in Loop mode. Generates a particle from that node travelling east (when Loop is turned off)
2- activates a wormhole. While continuing to press the node key, select a grid square as the destination for the wormhole. (e.g. press node x1y1. while holding x1y1, press mode 2. CONITINUING to hold the original node x1y1, press node x3y4).
3 - zeros a nodes attributes (only for the current plane).
4 - assigns the current planes nodal attributes to all other planes of a node.

Each "turn" represents one beat triggered by monomod.
Any particles present in the grid will have their positions updated, and the node they reside in will determine an action based upon its attributes.

Each plane represents a possibility of a node firing. In its initial state, plane one has a 20% chance of happening, plane two 40%, etc. When a particle strikes a node, a random number is generated (0-8). If that number is less than plane 1's probability, then whatever attributes are also assigned to that nodes plane will be used to determine what happens. If the number is more than 1's probability, then the same comparison will be done with plane 2's probability.

For instance: a particle, traveling south, strikes a node. (for this example, we will only consider the first two planes: just as if plane 3 and 4 had their probability assigned to 0)

The node has the following attirbutes:

Plane1: oct 0 note 0 prob 4 directions: north, south.
Plane2: oct 1 note 4 prob 6 directions: east, west.

The random number generated is a 7: nothing happens and the particle continues to travel south on the next turn.
The random number generated is a 6: plane 2 is struck: a note is played (note4,oct0), and the particle is split in two, traveling one east and one west on the next turn.
The random number generated is a 3: plane 1 is struck: no note is played (oct 0 note 0 == no note), but a new particle is created, so the old particle continues on southwards at the beginning of the next turn, joined by a new particle traveling in the opposite direction.

WTF?

Press button x1y1 (keep holding it!). Assign a direction (east). Press Mode 1 to make it a loopstart point. Press. Press x8y1 (to assign it a probability of 8: this means it will asways happen). (now let go of x1y1)
Press button x5y1 (keep holding it!) Assign a direction (west). Press x8y1 (probability 8). Now let go of x5y1.
Make sure loop is turn on. Start playing in Live. You should now have a particle bouncing back and forth between two red nodes.

Nodes change color when they have direction or wormhole attributes, but not when they are only assigned notes.
The maximum number of particles may be limited in the GUI.
Instead of generating a random number at each turn, you may assign that number in the GUI. This way you can work on one plane of probability at a time. Plane "9" in the GUI means random, this is the normal behavior.
The small white button in the bottom corner will open the note editor
Presets are stored via pattrstorage. They can be directly written or read from .json files.

There are lots of little things that need to be done. There will be a live-play mode very soon, where you can insert particles into the grid via MIDI in real time.

[[Category:Mods]]

Modlink

2012-07-19T19:28:32Z

Ground state: add category

== Video Tutorials ==

[http://www.youtube.com/watch?v=ylDHUlO_m1c MorphicField's Tutorial]

=='''Overview'''==

Modlink is a mod that allows connection to any standard monome patch as though it were a mod.

[[File:Modlink_pic.png]]

The top selection menu allows changing the communication protocol used to connect to the monome patch.

The title-bar also contains the unique instance number of the modlink. This number will also be present in any Bonjour listing available in a serialosc monome patch, so make sure when enabling a connection from serialosc that you choose the right modlink instance.

The prefix, input, and output port textboxes can be changed manually, or via serialosc. New settings initiated from serialosc will automatically be entered in the user interface.

Each individual instance of modlink will be initialized with a unique input port. This should prevent interference from other instances, but also means you'll have to be mindful of which instance is which when auto-connecting.

''Currently, most monomeserial and serialosc messages are supported. However, luminosity and cable messages will be ignored.''

----------

Here's a screenshot of 3 instances of modlink being used, 2 with SerialOSC connections (_xor and polygome), and one with MonomeSerial (molar).

[[File:Modlink_example.png]]

== Examples ==

Here's an example using the older Monolink plugin from b992. This setup is kind of redundant now, since LCC has been ported over to a mod.

Monolink using the BlockMod control surface and Live Clip Chopper:

These are the basic settings for getting the [http://www.maxforlive.com/library/device.php?id=230 Live Clip Chopper] to work with Monolink.

[[File:clipchopwin.jpg]]

Also, if you are using multiple versions of the Monolink plugin, make sure that each one has its own UDP port settings, otherwise you will get some strange interactions between each instance (e.g. feedback from one on the others grid, etc.).

[[Category:Mods]]

Max 6 issues

2012-07-01T15:59:25Z

Ground state: cafe

It's possible that some of these '''aren't''' Max 6 related, but that's what I'm testing with, so...

Probably good to specify the test environment:
* MBP Core i7 8G ram
* OSX 10.6.8 '''running 64-bit kernel''' - I have seen strange behavior with this, though not necessarily with Live/Max
* Live 8.3
* Max 6.0.4 (52278)
* Launchpad
* various other MIDI gear hanging off USB hubs here and there

===== aumboids =====
says:
<nowiki>
#N: extra arguments for message "funnel"</nowiki>

'''This error is fixed in my working versions, and will be included in the next official package.'''

===== binary =====
<nowiki>
mod_b993.js: Javascript TypeError: "this_device" is not a function, line 215
js: error calling function init</nowiki>

===== polygome =====
mode 4, the duration edit mode - bottom row of buttons doesn't mute

===== presscafe =====
help goes to "Presscafe" rather than "PressCafe" (I've already made a redirect)

Say... What '''is''' the difference between "cafe" and "presscafe"?

===== tintinnabulome=====
<nowiki>#N: extra arguments for message "r"
#N: extra arguments for message "s"</nowiki>

'''Spent a total of about 3 hours trying to determine where that comes from over the last year....it drives me nuts.'''
'''It's an artifact from the original, I think, but I haven't been able to route it out. I think its harmless. - a'''

===== general =====
Seems like editing one patch, then deleting it and adding/editing another will usually throw up something like this (although quitting Max in between seems to make it not happen):
<nowiki>
js: mod_b993.js: Javascript TypeError: client_menu is undefined, line 278
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function loadbang
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key</nowiki>

'''These type of errors are what I'm mainly interested in: they reflect how the mod.js and Python cores interact in Max6. I'm currently working on b994 revs of these core scripts, so anything strange happening with connection routines or entering/exiting/saving from the editor are very noteworthy, and extrememly helpful. It is because my implementation, by necessity, is so convoluted that I've delayed moving to Max6 for so long.'''

'''This particular problem is due to the wrong initalization order, and may be due some change in the behavior of [live.this_device]. I'm hoping to finish up with current Max5 stuff tonight and switch to Max6 for testing of a project tomorrow before release, so hopefully I'll be able to catch up with what's going on.'''

Max 6 issues

2012-07-01T15:53:52Z

Ground state: binary

It's possible that some of these '''aren't''' Max 6 related, but that's what I'm testing with, so...

Probably good to specify the test environment:
* MBP Core i7 8G ram
* OSX 10.6.8 '''running 64-bit kernel''' - I have seen strange behavior with this, though not necessarily with Live/Max
* Live 8.3
* Max 6.0.4 (52278)
* Launchpad
* various other MIDI gear hanging off USB hubs here and there

===== aumboids =====
says:
<nowiki>
#N: extra arguments for message "funnel"</nowiki>

'''This error is fixed in my working versions, and will be included in the next official package.'''

===== binary =====
<nowiki>
mod_b993.js: Javascript TypeError: "this_device" is not a function, line 215
js: error calling function init</nowiki>

===== polygome =====
mode 4, the duration edit mode - bottom row of buttons doesn't mute

===== presscafe =====
help goes to "Presscafe" rather than "PressCafe" (I've already made a redirect)

===== tintinnabulome=====
<nowiki>#N: extra arguments for message "r"
#N: extra arguments for message "s"</nowiki>

'''Spent a total of about 3 hours trying to determine where that comes from over the last year....it drives me nuts.'''
'''It's an artifact from the original, I think, but I haven't been able to route it out. I think its harmless. - a'''

===== general =====
Seems like editing one patch, then deleting it and adding/editing another will usually throw up something like this (although quitting Max in between seems to make it not happen):
<nowiki>
js: mod_b993.js: Javascript TypeError: client_menu is undefined, line 278
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function loadbang
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: default_color_map is undefined, line 84
js: error calling function set_color_map
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key
js: mod_b993.js: Javascript TypeError: stored_keys is undefined, line 441
js: error calling function key</nowiki>

'''These type of errors are what I'm mainly interested in: they reflect how the mod.js and Python cores interact in Max6. I'm currently working on b994 revs of these core scripts, so anything strange happening with connection routines or entering/exiting/saving from the editor are very noteworthy, and extrememly helpful. It is because my implementation, by necessity, is so convoluted that I've delayed moving to Max6 for so long.'''

'''This particular problem is due to the wrong initalization order, and may be due some change in the behavior of [live.this_device]. I'm hoping to finish up with current Max5 stuff tonight and switch to Max6 for testing of a project tomorrow before release, so hopefully I'll be able to catch up with what's going on.'''

Max 6 issues

2012-07-01T03:24:15Z

Ground state:

Max 6 issues

2012-07-01T02:47:59Z

Ground state:

It's possible that some of these '''aren't''' Max 6 related, but that's what I'm testing with, so...

aumboids says "#N: extra arguments for message "funnel""

presscafe: help goes to "Presscafe" rather than "PressCafe" (I've already made a redirect)

Max 6 issues

2012-07-01T02:47:39Z

Ground state: page created

It's possible that some of these '''aren't''' Max 6 related, but that's what I'm testing with, so...
aumboids says "#N: extra arguments for message "funnel""
presscafe: help goes to "Presscafe" rather than "PressCafe" (I've already made a redirect)

Presscafe

2012-06-30T00:09:32Z

Ground state: Redirected page to PressCafe

#REDIRECT [[PressCafe]]

Main Page

2012-06-29T18:15:39Z

Ground state: formatting

== Monomodular ==

First a tiny bit of history: Monomodular began as a multi-color [http://monome.org/devices monome] emulation experiment over two years ago. It was designed with live music performance as its primary goal. So: Monomodular is a modular environment for using (possibly multiple) [[#Supported controllers|supported grid-style controllers]] (APC40, Launchpad, etc.) with (possibly multiple) Max for Live (M4L) plugins (a.k.a. [[Mods]]), as well as a framework for M4L plugin development.

Monomodular is still under active development, and is being offered as a beta, but it '''is''' being used for both production '''and''' performance by its author and many others (you should, too!).

Most of the early Mods were ports of popular Max patches or M4L devices designed for use with the monome, but now the release includes many of amounra's own creations (which are not tied to any specific controller). The majority of the existing Mods are for MIDI generation and generative processes, but the Monomodular development framework allows developers to leverage the full power of Live + M4L + Max/MSP. The sky's the limit! See [[Help|Building your own Mods]].

== Installation ==

==== How? ====

<strike>
Download the installer and use its "Subversion" button to install the most recent version (recommended):

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_OSX.amxd OSX Installer]

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_Win.amxd Windows Installer]

If you are using Windows, you will need to install the command-line subversion tool, [http://www.sliksvn.com/en/download SlikSVN] (or something else which takes svn commands).
</strike>

SVN installation is not yet available in b993, so just download the complete [http://www.aumhaa.com/Monomodular/Monomodular_b993.zip Monomodular b993 Content] package (which contains installers for Win and OSX), unpack it somewhere convenient, then either double-click the appropriate .amxd for your platform, or drop same into an open Live set.

If you run into trouble, the [[Installation]] page contains a few tips and gotchas, as well as a more detailed explanation of how the installer works, for the curious.

==== What? ====

The Installer patch is a fairly simple M4L utility which reads information about your Live and Max installations and tries to determine where files should be put on your system. Because Monomodular is not an application in itself, but is instead a collection of scripts and Max patches, it needs to be installed a bit differently than most things. The installer patch gets some information from Ableton's log and the currently running instance of Live. This process is not perfect, however, and under certain circumstances you'll have to locate the correct installation paths manually. The installer will alert you if it is unable to locate something it needs.

If you have a persistent problem with installation, please contact amounra with the specifics, and a copy of Ableton's '''[[log.txt]]''', so that the installer can be improved.

The installer installs three main categories of files:

* '''Mods'''
:M4L patches which "do stuff" in conjunction with a grid controller. The list is growing, but you can go to the [[Mods]] page to learn a little bit about what's currently available. You can also access an information page on this wiki from within the plugin itself by hitting the Help button.
* '''Framework Scripts'''
:These are the Python scripts which
::* Allow your grid controller to interact with Live and link to the main Monomodular script.
::* Set up the main Monomodular script, the "hub" which controls interactions among the grid controller, Live, and Mods.
* '''Other Stuff'''
:Miscellaneous files which need to be here or there in order for things to work correctly.

==== Where? ====

If you need to know where certain files are located, or would like to change some things with the installation, please refer to the [[Manual Installation]] page.

== How Monomodular Works ==

Monomodular is roughly based on a server/client principle, with Monomodular acting as an intermediary between the various Mods and [[#Supported controllers|supported]] controllers.

As of version b993, Monomodular allows native communication with patches/M4L devices specifically designed to work with monome hardware, without needing anything else, using SerialOSC.

You can read a description of the basic functionality of the Monomodular-enabled control scripts on the [[How Monomodular Works]] page.
Each supported controller has its own page with further instructions and tips for usage.

====== Supported controllers ======

*[[How to use the AumPC scripts|Akai's APC 20 and APC 40]]

*[[How to use the BlockMod script|Livid's Block]]

*[[How to use the Codec script|Livid's Code]]

*[[How to use the iOs scripts|Apple's iPad, using either TouchOSC or Lemur]]

*[[How to use the LaunchMod script|Novation's Launchpad]]

*[[How to use the Ohm64 script|Livid's Ohm64]]

== What Comes with Monomodular ==

The [[Mods|Mods page]] lists all current mods. It's an evolving work-in-progress instruction and commentary on each plugin, so it's a good idea to check back from time to time for new information.

Monomodular editors style guide

2012-06-29T18:04:54Z

Ground state: Page creation. Don't call me a Nazi; I'm just an Editor :P

* No: Headers don't need bolding (<nowiki>== '''Heading''' ==</nowiki>) - they're already larger and bolder than body text.
* Yes: Space around '=' for headers (<nowiki>== Heading ==</nowiki>) - it's just that little bit easier to read the markup
* Yes: Space after '*' and '#' in lists - again, just a little easier to read the markup
* No: Don't double-newline after headers - they're already styled to be vertically offset from following text
* Yes: Double-newline after the *end* of a section. The default styling tends to make sections run together a bit

How Mod Works

2012-06-29T17:54:33Z

Ground state: style cleanup; "Supported Controllers" section now mirrors the same section from the Main Page

Monomodular is the hub of all communcations between [[Mods]] and the Monomodular capable controllers. Each client control script works in its own way, but the Monomodular standard is shared between all of them.

Monomodular controllers all have the capability of controlling a Monome256 workspace. Each one does it in its specific way. The only necessity required to integrate a controller with the Monomodular design is that it has an 8x8 grid of buttons. Other functionality is present on some controllers, but mainly, it works like this:

== The Grid ==

There is an 8x8 grid, which represents one quadrant of the Monome256 workspace in its normal mode.

In addition, it will display generic information about the status of Monomodular and its connected Mods when using the other controls below.

If you are not familiar with how a monome works, you might want to check this out:

http://en.wikipedia.org/wiki/Monome

and this:

http://monome.org/

But chances are if you've made it this far, you probably already know about monomes (and want one of your own!). Good thing for you, here it is.....

== The Shift Button ==

There is a Shift button, which, when pressed, does the following:

It allows navigation to one of those 4 quadrants by pressing one of the center 16 buttons, which will be lit to indicate which area is currently selected (either by colors or by different flashing states).

It causes the top row of buttons to indicate which of the 16 possible [[Mods]] is currently selected. The button on column 1, row 3 allows the user to select Mod 9-16 according to its toggle status.

It causes the second row of buttons to indicate which of the 16 possible channels the currently selected Mod is transmitting on (if it is a mono-channel instrument). The button on column 8, row 3 allows the user to select Mod 9-16 according to its toggle status.

It causes the bottom row of buttons to change over to 'Key Mode', and their status to be updated accordingly. The Key buttons are patch specific in functionality, but there are general conventions about how they are used in most of the plugins. Most of the time the left four will indicate and change the Mods 'mode', and the second four control timing of the Mod if it is slaved to its internal clock.

As of b993, the left column sixth button will toggle into/out of [[MonoLinkComponent|MonoLink]] mode, and will indicate whether the control surface has that mode engaged or not.

[[File:8x8_shift.png]]

== The Lock Button ==

There is a Lock button, which toggles whether the bottom row is 'shift-locked' to permanently be used in 'Key Mode'.

[[File:8x8grid_locked.png]]

== The Alt Button ==

By pressing the dedicated "alt" button on the controller, it is possible to access additional functionality from the "Key" buttons. If there are no dedicated key buttons, the user can either engage "lock", or hold "shift" before pressing pressing "alt" and use the bottom row of grid buttons to access these functions.

The first four buttons have no built in functionality, but may trigger a behavior that is specific to the mod that is currently selected.

The last four buttons always perform the following functions:

5: View mod in Live. This will bring up the mod's device in Lives detail view, and consequently select the track that it's on. There is unfortunately no way to navigate to it if its nested in a Device Rack, but this will select the Rack that its contained in.

6: Toggle mod Mute. If the mod has embedded mute functionality, this button will toggle whether it is muted. It will be lit if unmuted while "alt" is depressed.

7. Toggle mod Power. This will toggle the device on/off parameter of the currently selected mod Device in Live.

8. Select mod Device. On controllers that offer device control, this will select the mod's parameters as the currently controlled device for the dials on the controller.

[[File:8x8grid_alt.png]]

== MonoLinkComponent ==

A new component has been added to the Monomodular MIDI Remote Script as of b993 which allows the user to connect to monome-based patches with no need for m4l or any other 'bridge' applications running in the background. The MonoLinkComponent is currently considered "beta" (er....more beta than the rest of Monomodular), so test it thoroughly on your system before depending upon it. That said, most of the prerelease testers have had success with it.

For more info: [[MonoLinkComponent]]

== Mod Order ==

A Mod can be used simply by placing it on an appropriate track in your Live set. It will automatically be configured consecutively as the next Mod, and its position on the nav-grid will be indicated by a numbered block on the top left of the Mod's user interface (white block means 1-8, black block means 9-16). You can, however, change this enumeration manually in the plugin's UI, and other Mods positions will be adjusted accordingly. These changes are persistent so that the next time you load your set, everything will be in the same place.

[[File:Block1.png]]

== Mod Timing ==

Most of the Mods have their own internal timing engine that is sync'ed to Live's clock. This, however, may be disengaged in order to trigger the timing process of the plugin from an external source (see below).

For most of the Mods, timing can be controlled by the last four Keys. The first of these changes the timing to Quarter note divisions, the second to Eighth note divisions, and the third to Sixteenth note divisions. The last button toggles Triplet timing.

[[File:Grid timing.png]]

In addition to the key controls, most Mods also have a 'Timing Multiplier', which speeds the timing engine up by the chosen amount.

== Input and Output Settings ==

Each Mod has its own idea of how to get things in and out. For most, however, there is a fairly standard MIDI settings dialog which allows the user to change how things are routed.

To change these settings, press the 'MIDI' button. This will bring up a floating window with that Mod's MIDI settings.

[[File:Mod midi settings.png]]

By default, a Mod will transmit its output to the TrackOutput of its plugin. That means the data is going to be delivered to whatever is after it in the track its situated in. In this case, the Mod's channel setting has no effect, since Live does not care at all which channel MIDI data is transmitted on internally.

However, it is possible to use '[[NomeOut]]' nodes to channelize data within Live. By placing a [[NomeOut]] patch elsewhere in the Live set, and setting a Mod's output destination to that Nome patch, you can select where a Mod's output is received merely by changing its channel in Shift-mode. [[NomeOut]] is crossplatform, however it is likely to be less accurate for timing than using the default output or MIDI.

If you are using OSX, it is also possible to transmit and receive via the lh_midi external created by Leigh Hunt. This object is included with the Monomodular installation, and will allow you to choose (for instance) an IAC bus as the destination for your Mods data. You can then route that IAC bus as a Track input back to your project, with much lower and more predictable amounts of latency.

In addition, some Mods use MIDI for input as well. Their input source may be changed in the same way. In a situation where you would like to use another timing engine to drive the Mod, you should assign an appropriate source for that input, and define what its clock beat will be. Also, make sure to toggle off the 'Internal' button on the MIDI configuration page.

== Supported Controllers ==

For more detailed descriptions of controller-specific functionality, please refer to the links below:

*[[How to use the AumPC scripts|Details for the APC]]

*[[How to use the BlockMod script|Details for the Block]]

*[[How to use the Codec script|Details for the Code]]

*[[How to use the iOs scripts|Details for the iPad]]

*[[How to use the LaunchMod script|Details for the Launchpad]]

*[[How to use the Ohm64 script|Details for the Ohm64]]

Main Page

2012-06-29T17:44:40Z

Ground state: It occurs to me that since this equally about the Mods, maybe we should have link to the Mods page in the lead para >_<

== Monomodular ==

First a tiny bit of history: Monomodular began as a multi-color [http://monome.org/devices monome] emulation experiment over two years ago. It was designed with live music performance as its primary goal. So: Monomodular is a modular environment for using (possibly multiple) [[#Supported controllers|supported grid-style controllers]] (APC40, Launchpad, etc.) with (possibly multiple) Max for Live (M4L) plugins (a.k.a. [[Mods]]), as well as a framework for M4L plugin development.

Monomodular is still under active development, and is being offered as a beta, but it '''is''' being used for both production '''and''' performance by its author and many others (you should, too!).

Most of the early Mods were ports of popular Max patches or M4L devices designed for use with the monome, but now the release includes many of amounra's own creations (which are not tied to any specific controller). The majority of the existing Mods are for MIDI generation and generative processes, but the Monomodular development framework allows developers to leverage the full power of Live + M4L + Max/MSP. The sky's the limit!

== Installation ==

==== How? ====

<strike>
Download the installer and use its "Subversion" button to install the most recent version (recommended):

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_OSX.amxd OSX Installer]

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_Win.amxd Windows Installer]

If you are using Windows, you will need to install the command-line subversion tool, [http://www.sliksvn.com/en/download SlikSVN] (or something else which takes svn commands).
</strike>

SVN installation is not yet available in b993, so just download the complete [http://www.aumhaa.com/Monomodular/Monomodular_b993.zip Monomodular b993 Content] package (which contains installers for Win and OSX), unpack it somewhere convenient, then either double-click the appropriate .amxd for your platform, or drop same into an open Live set.

If you run into trouble, the [[Installation]] page contains a few tips and gotchas, as well as a more detailed explanation of how the installer works, for the curious.

==== What? ====

The Installer patch is a fairly simple M4L utility which reads information about your Live and Max installations and tries to determine where files should be put on your system. Because Monomodular is not an application in itself, but is instead a collection of scripts and Max patches, it needs to be installed a bit differently than most things. The installer patch gets some information from Ableton's log and the currently running instance of Live. This process is not perfect, however, and under certain circumstances you'll have to locate the correct installation paths manually. The installer will alert you if it is unable to locate something it needs.

If you have a persistent problem with installation, please contact amounra with the specifics, and a copy of Ableton's '''[[log.txt]]''', so that the installer can be improved.

The installer installs three main categories of files:

* '''Mods'''

:M4L patches which "do stuff" in conjunction with a grid controller. The list is growing, but you can go to the [[Mods]] page to learn a little bit about what's currently available. You can also access an information page on this wiki from within the plugin itself by hitting the Help button.

* '''Framework Scripts'''

:These are the Python scripts which
::* Allow your grid controller to interact with Live and link to the main Monomodular script.
::* Set up the main Monomodular script, the "hub" which controls interactions among the grid controller, Live, and Mods.

* '''Other Stuff'''

:Miscellaneous files which need to be here or there in order for things to work correctly.

==== Where? ====

If you need to know where certain files are located, or would like to change some things with the installation, please refer to the [[Manual Installation]] page.

== How Monomodular Works ==

Monomodular is roughly based on a server/client principle, with Monomodular acting as an intermediary between the various Mods and [[#Supported controllers|supported]] controllers.

As of version b993, Monomodular allows native communication with patches/M4L devices specifically designed to work with monome hardware, without needing anything else, using SerialOSC.

You can read a description of the basic functionality of the Monomodular-enabled control scripts on the [[How Monomodular Works]] page.
Each supported controller has its own page with further instructions and tips for usage.

====== Supported controllers ======

*[[How to use the AumPC scripts|Akai's APC 20 and APC 40]]

*[[How to use the BlockMod script|Livid's Block]]

*[[How to use the Codec script|Livid's Code]]

*[[How to use the iOs scripts|Apple's iPad, using either TouchOSC or Lemur]]

*[[How to use the LaunchMod script|Novation's Launchpad]]

*[[How to use the Ohm64 script|Livid's Ohm64]]

[[Help|Building your own Mods]]

== What Comes with Monomodular ==

The [[Mods|Mods page]] lists all current mods. It's an evolving work-in-progress instruction and commentary on each plugin, so it's a good idea to check back from time to time for new information.

Main Page

2012-06-29T17:41:52Z

Ground state: Second pass. I think this will hold us for a while. I get this itchy feeling it could be organized a *little* better, but I'm happy enough for now

== Monomodular ==

First a tiny bit of history: Monomodular began as a multi-color [http://monome.org/devices monome] emulation experiment over two years ago. It was designed with live music performance as its primary goal. So: Monomodular is a modular environment for using (possibly multiple) [[#Supported controllers|supported grid-style controllers]] (APC40, Launchpad, etc.) with (possibly multiple) Max for Live (M4L) plugins (a.k.a. Mods), as well as a framework for M4L plugin development.

Monomodular is still under active development, and is being offered as a beta, but it '''is''' being used for both production '''and''' performance by its author and many others (you should, too!).

Most of the early Mods were ports of popular Max patches or M4L devices designed for use with the monome, but now the release includes many of amounra's own creations (which are not tied to any specific controller). The majority of the existing Mods are for MIDI generation and generative processes, but the Monomodular development framework allows developers to leverage the full power of Live + M4L + Max/MSP. The sky's the limit!

== Installation ==

==== How? ====

<strike>
Download the installer and use its "Subversion" button to install the most recent version (recommended):

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_OSX.amxd OSX Installer]

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_Win.amxd Windows Installer]

If you are using Windows, you will need to install the command-line subversion tool, [http://www.sliksvn.com/en/download SlikSVN] (or something else which takes svn commands).
</strike>

SVN installation is not yet available in b993, so just download the complete [http://www.aumhaa.com/Monomodular/Monomodular_b993.zip Monomodular b993 Content] package (which contains installers for Win and OSX), unpack it somewhere convenient, then either double-click the appropriate .amxd for your platform, or drop same into an open Live set.

If you run into trouble, the [[Installation]] page contains a few tips and gotchas, as well as a more detailed explanation of how the installer works, for the curious.

==== What? ====

The Installer patch is a fairly simple M4L utility which reads information about your Live and Max installations and tries to determine where files should be put on your system. Because Monomodular is not an application in itself, but is instead a collection of scripts and Max patches, it needs to be installed a bit differently than most things. The installer patch gets some information from Ableton's log and the currently running instance of Live. This process is not perfect, however, and under certain circumstances you'll have to locate the correct installation paths manually. The installer will alert you if it is unable to locate something it needs.

If you have a persistent problem with installation, please contact amounra with the specifics, and a copy of Ableton's '''[[log.txt]]''', so that the installer can be improved.

The installer installs three main categories of files:

* '''Mods'''

:M4L patches which "do stuff" in conjunction with a grid controller. The list is growing, but you can go to the [[Mods]] page to learn a little bit about what's currently available. You can also access an information page on this wiki from within the plugin itself by hitting the Help button.

* '''Framework Scripts'''

:These are the Python scripts which
::* Allow your grid controller to interact with Live and link to the main Monomodular script.
::* Set up the main Monomodular script, the "hub" which controls interactions among the grid controller, Live, and Mods.

* '''Other Stuff'''

:Miscellaneous files which need to be here or there in order for things to work correctly.

==== Where? ====

If you need to know where certain files are located, or would like to change some things with the installation, please refer to the [[Manual Installation]] page.

== How Monomodular Works ==

Monomodular is roughly based on a server/client principle, with Monomodular acting as an intermediary between the various Mods and [[#Supported controllers|supported]] controllers.

As of version b993, Monomodular allows native communication with patches/M4L devices specifically designed to work with monome hardware, without needing anything else, using SerialOSC.

You can read a description of the basic functionality of the Monomodular-enabled control scripts on the [[How Monomodular Works]] page.
Each supported controller has its own page with further instructions and tips for usage.

====== Supported controllers ======

*[[How to use the AumPC scripts|Akai's APC 20 and APC 40]]

*[[How to use the BlockMod script|Livid's Block]]

*[[How to use the Codec script|Livid's Code]]

*[[How to use the iOs scripts|Apple's iPad, using either TouchOSC or Lemur]]

*[[How to use the LaunchMod script|Novation's Launchpad]]

*[[How to use the Ohm64 script|Livid's Ohm64]]

[[Help|Building your own Mods]]

== What Comes with Monomodular ==

The [[Mods|Mods page]] lists all current mods. It's an evolving work-in-progress instruction and commentary on each plugin, so it's a good idea to check back from time to time for new information.

Main Page

2012-06-29T01:24:27Z

Ground state: there's already a Log.txt page! Who knew!

== Monomodular ==

'''Monomodular''' is a modular environment for using grid-style controllers with Max For Live plugins, as well as a framework for M4L plugin development. It began as a multi-color monome experiment over two years ago. It was designed with live musical performance as its most important goal. It is still under active development, and is being offered as beta, but is being used for both production and performance by its author and many others (you should, too!).

Monomodular is roughly based on a server/client principle, with Monomodular acting as an intermediary between different plugins and grid controllers.

[This should probably be simplified, with the bulk being moved to a more technical page] The basic idea is that Monomodular offers multiple simultaneous controllers access to multiple simultaneous plugins, and does so in a seamless and transparent fashion. Monomodular stores the states of all its clients, and is capable of interpreting a library of standard functions which are called from each individual control surface type in such a manner so that it does not need to be aware of what kind of control surface is connected to it in order to interpret its calls or correctly format its returns to the receiving component. The type of data its stores is fairly generic and conforms to the monome standard in some ways, but is also fairly arbitrary in that the core can be easily modified to store different types of data to suit the situation (for instance, it has been easily adapted to handle data types and addresses for both the Livid Code and CNTRL:R hardware devices).

As of version b99, the core of Monomodular is a Python control surface plugin which runs in Ableton Live's proprietary Python environment, contains a basic framework for communicating with [[#Supported devices|several types of hardware]]. It allows communication between up to 5 grid controllers with up to 16 client patches directly from the surface of the controller. It gives basic functionality of navigating and displaying a Monome256 workspace, and provides the base functionality for quickly writing or converting new plugins to work with its format.

As of version b993, the Monomodular Python script also contains socket functionality which allows it to natively communicate with devices designed to work with monome hardware without any further component needs. It publishes via Bonjour its address and ports, and communicates directly from the Python workings within Live.

There are many client patches included with the suite. Most of the early patches were ports of popular monome patches, but now the release includes many of amounra's own creations. The majority are for MIDI generation and generative processes, but the capabilities for using Monomodular are only limited by the imagination of the scripter.

On the MaxMSP side of things, the Monomodular format is largely dependent upon a single javascript object, which can be manipulated in many different ways. In addition to using the prebuilt mods, it offers the capability of creating one's own custom patches easily in MaxforLive and using them within the framework of Monomodular, or adapting patches which you've already built to be used with a grid controller.

== Installation ==

==== How? ====

<strike>
Download the installer and use its "Subversion" button to install the most recent version (recommended):

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_OSX.amxd OSX Installer]

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_Win.amxd Windows Installer]

If you are using Windows, you will need to install the command-line subversion tool, [http://www.sliksvn.com/en/download SlikSVN] (or something else which takes svn commands).
</strike>

SVN installation is not yet available in b993, so just download the complete [http://www.aumhaa.com/Monomodular/Monomodular_b993.zip Monomodular b993 Content] package (which contains installers for Win and OSX), unpack it somewhere convenient, then either double-click the appropriate .amxd for your platform, or drop same into an open Live set.

If you run into trouble, the [[Installation]] page contains a few tips and gotchas, as well as a more detailed explanation of how the installer works, for the curious.

==== What? ====

The Installer patch is a fairly simple M4L utility which reads information about your Live and Max installations and tries to determine where files should be put on your system. Because Monomodular is not an application in itself, but is instead a collection of scripts and Max patches, it needs to be installed a bit differently than most things. The installer patch gets some information from Ableton's log and the currently running instance of Live. This process is not perfect, however, and under certain circumstances you'll have to locate the correct installation paths manually. The installer will alert you if it is unable to locate something it needs.

If you have a persistent problem with installation, please contact amounra with the specifics, and a copy of Ableton's '''[[log.txt]]''', so that the installer can be improved.

The installer installs three main categories of files:

* '''Mods'''

:M4L patches which "do stuff" in conjunction with a grid controller. The list is growing, but you can go to the [[Mods]] page to learn a little bit about what's currently available. You can also access an information page on this wiki from within the plugin itself by hitting the Help button.

* '''Framework Scripts'''

:These are the Python scripts which
::* Allow your grid controller to interact with Live and link to the main Monomodular script.
::* Set up the main Monomodular script, the "hub" which controls interactions among the grid controller, Live, and Mods.

* '''Other Stuff'''

:Miscellaneous files which need to be here or there in order for things to work correctly.

==== Where? ====

If you need to know where certain files are located, or would like to change some things with the installation, please refer to the [[Manual Installation]] page.

== How Monomodular Works ==

You can read a description of the basic functionality of every Monomodular-enabled control script on the [[How Monomodular Works]] page.
More detailed information is available at each controller's page.

====== Supported devices ======

*[[How to use the AumPC scripts|Akai's APC 20 and APC 40]]

*[[How to use the BlockMod script|Livid's Block]]

*[[How to use the Codec script|Livid's Code]]

*[[How to use the iOs scripts|Apple's iPad, using either TouchOSC or Lemur]]

*[[How to use the LaunchMod script|Novation's Launchpad]]

*[[How to use the Ohm64 script|Livid's Ohm64]]

[[Help|Building your own Mods]]

== What Comes with Monomodular ==

The [[Mods|Mods page]] lists all current mods. It's an evolving work-in-progress instruction and commentary on each plugin, so it's a good idea to check back from time to time for new information.

Main Page

2012-06-29T00:12:08Z

Ground state: First pass at a general overhaul for readability, organization, and clarity. tl;dr wall of text at the top of the page needs the most work - much of it should probably go to a How It Works page

== Monomodular ==

'''Monomodular''' is a modular environment for using grid-style controllers with Max For Live plugins, as well as a framework for M4L plugin development. It began as a multi-color monome experiment over two years ago. It was designed with live musical performance as its most important goal. It is still under active development, and is being offered as beta, but is being used for both production and performance by its author and many others (you should, too!).

Monomodular is roughly based on a server/client principle, with Monomodular acting as an intermediary between different plugins and grid controllers.

[This should probably be simplified, with the bulk being moved to a more technical page] The basic idea is that Monomodular offers multiple simultaneous controllers access to multiple simultaneous plugins, and does so in a seamless and transparent fashion. Monomodular stores the states of all its clients, and is capable of interpreting a library of standard functions which are called from each individual control surface type in such a manner so that it does not need to be aware of what kind of control surface is connected to it in order to interpret its calls or correctly format its returns to the receiving component. The type of data its stores is fairly generic and conforms to the monome standard in some ways, but is also fairly arbitrary in that the core can be easily modified to store different types of data to suit the situation (for instance, it has been easily adapted to handle data types and addresses for both the Livid Code and CNTRL:R hardware devices).

As of version b99, the core of Monomodular is a Python control surface plugin which runs in Ableton Live's proprietary Python environment, contains a basic framework for communicating with [[#Supported devices|several types of hardware]]. It allows communication between up to 5 grid controllers with up to 16 client patches directly from the surface of the controller. It gives basic functionality of navigating and displaying a Monome256 workspace, and provides the base functionality for quickly writing or converting new plugins to work with its format.

As of version b993, the Monomodular Python script also contains socket functionality which allows it to natively communicate with devices designed to work with monome hardware without any further component needs. It publishes via Bonjour its address and ports, and communicates directly from the Python workings within Live.

There are many client patches included with the suite. Most of the early patches were ports of popular monome patches, but now the release includes many of amounra's own creations. The majority are for MIDI generation and generative processes, but the capabilities for using Monomodular are only limited by the imagination of the scripter.

On the MaxMSP side of things, the Monomodular format is largely dependent upon a single javascript object, which can be manipulated in many different ways. In addition to using the prebuilt mods, it offers the capability of creating one's own custom patches easily in MaxforLive and using them within the framework of Monomodular, or adapting patches which you've already built to be used with a grid controller.

== Installation ==

==== How? ====

<strike>
Download the installer and use its "Subversion" button to install the most recent version (recommended):

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_OSX.amxd OSX Installer]

[http://www.aumhaa.com/Monomodular/Monomodular_Installer_Win.amxd Windows Installer]

If you are using Windows, you will need to install the command-line subversion tool, [http://www.sliksvn.com/en/download SlikSVN] (or something else which takes svn commands).
</strike>

SVN installation is not yet available in b993, so just download the complete [http://www.aumhaa.com/Monomodular/Monomodular_b993.zip Monomodular b993 Content] package (which contains installers for Win and OSX), unpack it somewhere convenient, then either double-click the appropriate .amxd for your platform, or drop same into an open Live set.

If you run into trouble, the [[Installation]] page contains a few tips and gotchas, as well as a more detailed explanation of how the installer works, for the curious.

==== What? ====

The Installer patch is a fairly simple M4L utility which reads information about your Live and Max installations and tries to determine where files should be put on your system. Because Monomodular is not an application in itself, but is instead a collection of scripts and Max patches, it needs to be installed a bit differently than most things. The installer patch gets some information from Ableton's log and the currently running instance of Live. This process is not perfect, however, and under certain circumstances you'll have to locate the correct installation paths manually. The installer will alert you if it is unable to locate something it needs.

If you have a persistent problem with installation, please contact amounra with the specifics, and a copy of Ableton's '''log.txt''' file [location?], so that the installer can be improved.

The installer installs three main categories of files:

* '''Mods'''

:M4L patches which "do stuff" in conjunction with a grid controller. The list is growing, but you can go to the [[Mods]] page to learn a little bit about what's currently available. You can also access an information page on this wiki from within the plugin itself by hitting the Help button.

* '''Framework Scripts'''

:These are the Python scripts which
::* Allow your grid controller to interact with Live and link to the main Monomodular script.
::* Set up the main Monomodular script, the "hub" which controls interactions among the grid controller, Live, and Mods.

* '''Other Stuff'''

:Miscellaneous files which need to be here or there in order for things to work correctly.

==== Where? ====

If you need to know where certain files are located, or would like to change some things with the installation, please refer to the [[Manual Installation]] page.

== How Monomodular Works ==

You can read a description of the basic functionality of every Monomodular-enabled control script on the [[How Monomodular Works]] page.
More detailed information is available at each controller's page.

====== Supported devices ======

*[[How to use the AumPC scripts|Akai's APC 20 and APC 40]]

*[[How to use the BlockMod script|Livid's Block]]

*[[How to use the Codec script|Livid's Code]]

*[[How to use the iOs scripts|Apple's iPad, using either TouchOSC or Lemur]]

*[[How to use the LaunchMod script|Novation's Launchpad]]

*[[How to use the Ohm64 script|Livid's Ohm64]]

[[Help|Building your own Mods]]

== What Comes with Monomodular ==

The [[Mods|Mods page]] lists all current mods. It's an evolving work-in-progress instruction and commentary on each plugin, so it's a good idea to check back from time to time for new information.

How to use the LaunchMod script

2012-06-28T20:23:48Z

Ground state: fix Key buttons are on the *right* side, not the left :); clarify default functionality

The general functionality of the stock Live script provided by Novation has been retained, and it should work exactly as the stock script does in every respect, except for one:

If you press both User1 and User2 at the same time, this should enter Mod Mode.

[[File:Lp_to_modMode.png]]

Once in Mod Mode, the Session button is Shift. The User1 button is Lock. The User2 button is Alt.

The nav buttons will navigate the Monomodular grid, and the right 8 buttons control the Keys.

To exit Mod Mode, simply press the Mixer button, which should be illuminated red.

[[File:Lp modMode.png]]

Enjoy :)

== Video Tutorials ==

[http://www.youtube.com/watch?v=r770tr4lufc MorphicField's Tutorial]

[http://www.youtube.com/watch?v=JeNlZuKO33A MorphicField's Tutorial #2]

[http://www.youtube.com/watch?v=ylDHUlO_m1c MorphicField's Tutorial #3]