Architect: Show your projects here

Official support for:
2104 posts since 25 Aug, 2003 from Bournemouth, UK

Post Wed Aug 28, 2019 8:08 am

As requested, a specific sticky thread in which people can post their macros, modules, or any other home-brew Architect creations they wish to share with the community.

There is also a sibling thread for requests for specific macros that other people may either have or be willing to build.

Thanks all.
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.

User avatar
704 posts since 7 Dec, 2009 from GWB

Post Sun Dec 08, 2019 6:06 am

MFELL: a patch to merge two MIDI streams

Here's another of my "nobody asked for it" patches. There's already been some discussion of it on the Architect OG thread here: viewtopic.php?p=7598277#p7598277

You can download the patch here:

MFELL works with two monophonic MIDI streams as a filter to create a new stream, where notes play only when both streams are playing: sort of a Boolean AND merge. The patch favors the pitch and velocity values of the "first" stream. It's written as a plugin to be used in the DAW of your choice, which is Reaper at my house.


The basic setup is a folder containing two tracks, which simplifies the routing. Routing automatically ends up in the enclosing folder, which is where you'd place Architect and the MFELL patch. The MIDI stream whose pitch/velocity you want to keep should go in Channel 1, the other MIDI stream should go in Channel 2. Set the properties of the MIDI files to output on these MIDI channels respectively. Reaper's default is to "consume" MIDI on a track, so Architect should pass only the merged stream onto the next plugin, which should be your VSTi.


MFELL takes the incoming two channel MIDI stream, and via [get channel] [modulo] 2, splits the two streams using [branch]. I'm assuming here that the two channels are 1 and 2, so the [modulo] transforms that to 1 and 0, or true/false input to [branch]. I used [modulo] in stead of subtraction because it reverses the stream order, placing Channel 1 to the right of the patch for sanity's sake.

The two streams are broken out into their separate elements via the [MIDI to tuple] [unpack tuple] pair. Channel 1's pitch information is fed into [pack noteon] without further processing. The velocity data of both streams go into the macro [Bit AND]:


[Bit AND] clamps the 0-127 data range of the velocity streams into a 0-1 range: essentially "playing"/"not playing". The clamped data is bitwise [&]-ed with each other, either stream triggering evaluation. The result goes back up to the main patch.


[change] takes the same two velocity streams and uses [order] to create two moments of execution for the data. The first reads [latch] before it's written to, creating a data store of the previous stream value. [!=] then evaluates true for the current datum being different from the previous, and false for being the same as previous. This state controls [branch] which outputs the velocity value only when it has changed from X -> 0 or 0 -> X. "Duplicates" 0 -> 0, X -> X are tossed out.

Back at the main level of the patch the result of [Bit AND] is multiplied by the result of [change] to permit noteons only when both streams are in the noteon state.

This merged velocity stream joins the pitch data in [pack noteon] along with default values of Channel 1 as MIDI output channel, and "false" as Architect noteon/noteoff coupling. I realized that you can use [pack noteon] for noteoffs as well, as they're just noteons with velocity zero. This does bypass Architects policing of the MIDI stream. MIDI is then output to host.

The patch is released without any reservation of rights. It's yours to do with as you please, but don't necessarily expect any support from me. I'm happy to discuss the patch or respond to questions, and may work further on it or bug fix depending on my interest. I hope you get something from the code!
Tranzistow Tutorials:
Xenakis in America:

User avatar
704 posts since 7 Dec, 2009 from GWB

Post Thu Dec 19, 2019 1:06 pm

Pattern Resume:

I had discussed this awhile back with Colin and posted a now-awkward-looking solution to the issue of Architect's sequencers resetting to the first step on pattern change. Another behavior would be for the step to remain unchanged over a pattern switch.

The previous discussion in here:
colin@loomer wrote:
Mon Jun 10, 2019 9:26 am
and here:
cturner wrote:
Mon Jun 10, 2019 1:05 pm
Quite unexpectedly, I found myself working on this problem again today, and took Colin's suggestion to use "play step/step out" to jiggle the sequencer position appropriately.

The XML preset is here: ...


The preset is designed to demonstrate that the patch works correctly. You'll want to fiddle with it to extract the parts that are useful to you.

The logic at the top, above the two [data] objects with values "1" and "2", is demo code that switches to pattern "1" every 6 quarter notes, and then to pattern "2" after a delay of 3 quarter notes. If you look at patterns 1 and 2 at bottom left, you'll notice that they're identical. So the listening test is that the pattern plays through without any glitches caused by the pattern switch. (There's a pattern "0" so you can audition an actual change of pattern without much trouble.)

As usual, the [MIDI output] is set to "Host". The patterns are for drums at D3 and E3, which I believe are MIDI standard for "snare" and "electric snare".

The [data] values "1" and "2", plus [true] provide the pattern switching mechanism for the [mono sequencer] object. The actual work is done below, where the step out is [latch]-ed, and on switch adds 1 to the latched step out, then constrains the range back to 0-15 courtesy of [modulo] 16. The latch and math are also triggered by the pattern switch logic, and thus sets Play Step to the next pattern step after the previous. EDIT: Note that the "16" in [modulo] is hard-coded, so if your sequence is anything other than that number of steps, you'll have to change that value, or write something that gives it some intelligence.

As usual, don't expect support, but you're free to do whatever with the code.

Tranzistow Tutorials:
Xenakis in America:

User avatar
704 posts since 7 Dec, 2009 from GWB

Post Sat Feb 29, 2020 6:00 am

Burraston - Basic Cellular Automata Elements

Well, given the expressed opinion of Architect native objects over on the Beta thread, I almost didn't post this. Likely a bit briefer account of the coding than in the past.

A ZIP file of the preset and screen shots is here: ~350Kb download.

This is another of my resurrections of old Max/MSP efforts in Architect, so some of the story is in the porting:


The CA generates a single monophonic line suitable for drum programming, although the basic building blocks can be used in more complicated ways. The Max patch is based on 480 ticks in a 4/4 bar, provided by [metro @interval 4 ticks][counter 0 0 479]. The (global) [transport] element is also essential to this configuration. At top, [bang][Uzi 480] [decide] [zl 480 group 480] provides an initial random seed to a [multislider] used as a visualization of one generation of the automaton.

Update from generation to generation is handled by the center section of the patch. In this and the following Architect preset, the CA is configured as 1D with a neighborhood of 3--the very basic CAs that Stephen Wolfram investigated so thoroughly.

A [bang][Uzi 480][counter 0 479] again iterates through the CA population. The CA is arranged as a circular array by convention so in this case, as neighborhood lookup would be elements 4 and 6 for element 5, it would also be 479 and 1 for element 0, and 478 and 0 for element 479.

The next piece of the patch handles this condition. In the middle the current counter value is passed directly to [zl 480 lookup] (which holds a copy of the current CA generation). Given right-to-left order of execution in Max, the right hand [+479][% 480] "rotates the array 360 degrees minus one element" to obtain the lower neighbor with circularity. The [+1] [% 480] is a bit easier to visualize, calculating the higher neighbor with wrap around.

The values of the 3-neighborhood are passed sequentially to [zl group 3] to form a sub-array, and then [unpack 0 0 0]'ed into their separate parallel values. The configuration of [*4], [*2] and [+]s shift and combine the three values to form the rule index 0-255, which then is used to compute the new cell value via a [coll], essentially an 8 element array. This sequential process is grouped into 480 new cell values, constituting a new generation of the automaton.

The Architect Port

The Architect version has some similarity with the Max version above. (I spent time in the Max section providing some context for CAs, so if you skipped that section, and are unfamiliar with cellular automata, you might find the following a bit terse.)


The shot above is the preset, but let's start with the simpler details and work outward:


[build array] contains the "new" generation of the 16-element cellular automaton. The array is a series of 0s and 1s--black cells and white--that are then multiplied by 50 to get that specific MIDI note. The resulting array in passed to the pitch row of a [mono step sequencer]. The original 0/1 array is passed to the trigger row of the sequencer. MIDI output goes to the host, as I'm using the plugin version of Architect.


The CA array is seeded by a [Bernoulli distribution list] again, a 16-element array. Note the probability of the distribution can be set to something other than 0.5/50%. The resulting seed array is then stored in [cells], and also loaded into a lookup for computing the new generation of the automaton.


CA rules are generated differently than in the Max version. The Max version required different saved [coll]s for the 256 rules, but the Architect version simply computes an array based on the rule number, in this case 170. 256 rules imply an 8-bit number, so an 8-iteration [for] loop controls a bitwise right shift [>>>] that is then masked by the bitwise [&] of 1 (lowest bit). This contributes to a tuple formed by [pair] that takes the [for] counter and shifted bit value to build a rule array of 0s and 1s. Note that as convention has array indexes growing from left-to-right, and binary digits growing from right-to-left, the array reverses the order of the rule. But as the index is the reference, everything comes out okay.


The iteration to access the 3-cell neighborhood is quite like the Max version. A 16 element [arithmetic sequence] is generated: [0, 1, 2, 3, 4, 5... 13, 14, 15] which is iterated through [for each]. As evaluation order in Architect is roughly the reverse of Max, an [order] object clarifies what's happening. The lower neighbor is obtained via [15][+][16][modulo], and the higher neighbor via [1][+][16][modulo]. The [order] is actually more critical for the "middle" neighbor/"current cell", as top-to-bottom evaluation would required some odd object layout to naturally position the evaluation. The neighbors are grouped by the template [[$0, $1, $2]] which converts the sequence into an array, which is passed to [get element] on the final 3-neighbor calculation. This takes advantage of the vector computation of many of the array objects in Architect. [get element] contains the current CA generation array.


Applying the rule is again quite similar to Max. Here though, one can simply [pop] the last element of the neighbor array to feed the index computation. Note that the computation is arranged in the reverse of the Max patch as we are working through the array via [pop], last to first. The resulting number forms an index into the 3-neighbor rule, which has been sent from the rule generator to [get element]. The result, and the current element counter coming from "way above" via the [for each], are formed into a tuple with [pair], which builds the new generation in [build array].

. . . .

The code is released with my usual "you can do anything you like with it, but don't necessarily expect support" terms. I hope you find the objects useful!
Tranzistow Tutorials:
Xenakis in America:

127 posts since 11 Mar, 2014

Post Sat Feb 29, 2020 11:15 am

Very cool. Thanks for sharing!

User avatar
704 posts since 7 Dec, 2009 from GWB

Post Sun Mar 01, 2020 6:57 am

Prior to the creation of this thread, there were a lot of user contributions to be found in the "Can Anyone Make a * Script?" thread. I thought I'd extricate mine to make them more accessible to new comers, and would encourage the other posters to do the same. ThomasHelzle, mannymag, AZZIN: I'm looking at you! ;-)

Turing Random Source
GUI Overhaul by Thomas Helzle:

Chaotic Metronome

Basic Listener

Xenakian Sieves

14-bit CC Automation

Wigout LFO

MFELL: Merge Two MIDI Streams

Pattern Resume

Burraston: Basic Cellular Automata Elements
Tranzistow Tutorials:
Xenakis in America:

User avatar
116 posts since 25 Jul, 2004 from Italy

Post Wed Mar 04, 2020 1:14 pm

OK, time to move few posts on this thread.

A_MUSINUM: a port of Musinum algorithm to Architect

Hello, attached to this post there is a port of the Musinum algorithm ( developed by L. Kindermann, implemented in Architect.
This is an interesting algorithm, both from a musical as well as a mathematical point of view. Starting from a counter "i" a "number" is produced (from a "start" number and a "step"); the number is the converted in a different "base" and the single digits of the new number are summed up. For example, (from the Musinum site):

Code: Select all

     decimal  binary  sum of
     number   number  digits    Tone    2nd     4th   
	1       1       1       c               
	2       10      1       c       c       
	3       11      2       d       .       
	4       100     1       c       c       c
	5       101     2       d       .       .
	6       110     2       d       d       .
	7       111     3       e       .       . 
	8       1000    1       c       c       c 
	9       1001    2       d       .       .
	10      1010    2       d       d       .
	11      1011    3       e       .       .
	12      1100    2       d       d       d
Please note the colums 2nd and 4th: here we have a "self-similarity" effect, which is a very interesting property of the output series.
The architect implementation implements the following (Matlab/Octave) code (with some limitations):

Code: Select all

% example initialization
N = 1000;
start = 0;
step =1;
base = 2;

% main loop
for i = 1:N

  num = start + i*step;

  D = dec2base(num,base);
  L = length(D);
  temp = 0;
  for j = 1:L
    temp = temp + str2num(D(j));  

  out(i) = temp;

Now, if you have Matlab/Octave on your computer try the following:
% in case of base 2

% in case of base 3

and you have identical sequences, i.e. self-similar.

The Architect implementation is centered on a macro ("musi_num") which has the following inlets:

- input: an incremental/decremental number triggered by a Metronome, for example set to 1/8
- step: (>=1), as in above code
- start: starting integer (>=0), as in above code
- base: numerical base in which the number is converted
- max range: maximum midi note range on which the algorithm is bounded (def. 66)
- min range: minimum midi note range on which the algorithm is bounded (def. 46)

The main output is a number (left outlet) that can be easily converted into a midi note, while an experimental output* (right outlet) provides a number between [0-1] that is translated to midi velocity by means of a-linmap macro. These two ouput can then be passed through some midi processing (execution probability, force to scale etc.). Attached there is a simple implementation with 1 Midi channel in output.

Experiment with the different parameters, esp. "step" and "base", but also with increasing and decreasing input numbers ("UP", "DOWN") to get interesting sequences. To this aim, a simple graphical interface is provided, which allows the selection of the main parameters as well as scale, min/max midi velocity and channel probability. The default output is Midi OUT, so you have to attach a midi instrument outside Architect or switch the output to Track<N> (internal to Architect).

Suggestions, feedback, error reports are welcome.

Have fun,


*this idea is taken by the Musinum implementation in Pure Data by M. Brinkmann.

The following is a piano piece generated with two instances of the algorithm.
You do not have the required permissions to view the files attached to this post.
Last edited by AZZIN on Wed Mar 04, 2020 1:24 pm, edited 2 times in total.

User avatar
116 posts since 25 Jul, 2004 from Italy

Post Wed Mar 04, 2020 1:22 pm

A-CHAOS: a chaos library for architect

Hello all, during early 2019 I enjoyed a lot tweaking with Architect and I had fun in creating a small library project implementing chaotic/fractal algorithms - I called it "a-chaos" ("a" stands for Architect). It is a set of .frag files in a folder, that you need to extract from the attached zip archive and put (the complete folder) on the Architect fragments folder on your system. I attached also a small manual. It contains the clifford, dejong, hopalong, henon, duffing, lorenz and logistic maps (thanks cturner!).
If you want to play with these toys: once you copied the a-chaos folder in the Fragment folder you have the macros available by clicking the right mouse button in the architect "graph". Attach a metronome on the "step" inlet (the rightmost one) and the macro will generate sequences of values from each algorithm triggered by the metro signal. These sequences, in general, need to be mapped to meaningful midi values like pitch, velocity, cutoff, duration and so on, to generate nice and "unexpected" results :wink: . To this aim, the "a-linmap" macro is also part of the collection.
Why not using the LUA scripting for implementing this? That would have been easier, but with less fun.. Comments, feedback, anything, welcome. Enjoy :).
You do not have the required permissions to view the files attached to this post.

User avatar
704 posts since 7 Dec, 2009 from GWB

Post Tue May 05, 2020 5:42 am

Nice to see your work posted here AZZIN. Cheers!
Tranzistow Tutorials:
Xenakis in America:

User avatar
3016 posts since 22 Mar, 2009 from gent

Post Fri Jul 17, 2020 3:13 pm

Simple ,yet easy to use note +delay ( really not on par with the genius stuff posted on this page :)
Perfect for live use , swinging hihats etc..
Load as many as you want
You do not have the required permissions to view the files attached to this post.
Eyeball exchanging
Soul calibrating ..frequencies

Return to “Loomer”