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: Show your projects here
-
- KVRAF
- Topic Starter
- 2681 posts since 25 Aug, 2003 from Bournemouth, UK
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRian
- 698 posts since 7 Dec, 2009 from GWB
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: http://vze26m98.net/loomer/MFELL/MFELL-191207.zip
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!
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: http://vze26m98.net/loomer/MFELL/MFELL-191207.zip
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!
-
- KVRian
- 698 posts since 7 Dec, 2009 from GWB
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:
The XML preset is here: http://vze26m98.net/loomer/Pattern_Resu ... 191219.zip
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.
Enjoy!
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:
and here:
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: http://vze26m98.net/loomer/Pattern_Resu ... 191219.zip
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.
Enjoy!
-
- KVRian
- 698 posts since 7 Dec, 2009 from GWB
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: http://vze26m98.net/loomer/Burraston/Burraston.zip ~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!
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: http://vze26m98.net/loomer/Burraston/Burraston.zip ~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!
-
- KVRian
- 698 posts since 7 Dec, 2009 from GWB
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
viewtopic.php?p=7278261#p7278261
GUI Overhaul by Thomas Helzle:
viewtopic.php?p=7280771#p7280771
Chaotic Metronome
viewtopic.php?p=7280355#p7280355
viewtopic.php?p=7284039#p7284039
Basic Listener
viewtopic.php?p=7290355#p7290355
viewtopic.php?p=7302518#p7302518
viewtopic.php?p=7303164#p7303164
Xenakian Sieves
viewtopic.php?p=7309910#p7309910
14-bit CC Automation
viewtopic.php?p=7311970#p7311970
Wigout LFO
viewtopic.php?p=7322368#p7322368
viewtopic.php?p=7323475#p7323475
viewtopic.php?p=7328046#p7328046
MFELL: Merge Two MIDI Streams
viewtopic.php?p=7598277#p7598277
viewtopic.php?p=7600213#p7600213
Pattern Resume
viewtopic.php?p=7613274#p7613274
Burraston: Basic Cellular Automata Elements
viewtopic.php?p=7679962#p7679962
Turing Random Source
viewtopic.php?p=7278261#p7278261
GUI Overhaul by Thomas Helzle:
viewtopic.php?p=7280771#p7280771
Chaotic Metronome
viewtopic.php?p=7280355#p7280355
viewtopic.php?p=7284039#p7284039
Basic Listener
viewtopic.php?p=7290355#p7290355
viewtopic.php?p=7302518#p7302518
viewtopic.php?p=7303164#p7303164
Xenakian Sieves
viewtopic.php?p=7309910#p7309910
14-bit CC Automation
viewtopic.php?p=7311970#p7311970
Wigout LFO
viewtopic.php?p=7322368#p7322368
viewtopic.php?p=7323475#p7323475
viewtopic.php?p=7328046#p7328046
MFELL: Merge Two MIDI Streams
viewtopic.php?p=7598277#p7598277
viewtopic.php?p=7600213#p7600213
Pattern Resume
viewtopic.php?p=7613274#p7613274
Burraston: Basic Cellular Automata Elements
viewtopic.php?p=7679962#p7679962
-
- KVRist
- 123 posts since 25 Jul, 2004 from Italy
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 (https://reglos.de/musinum/) 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):
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):
Now, if you have Matlab/Octave on your computer try the following:
% in case of base 2
out(1:20)
out(2:2:40)
out(4:4:80)
% in case of base 3
out(1:20)
out(3:3:90)
out(9:9:180)
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,
Alberto
*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.
https://soundcloud.com/albertoz/praelude-for-a-robot
A_MUSINUM: a port of Musinum algorithm to Architect
Hello, attached to this post there is a port of the Musinum algorithm (https://reglos.de/musinum/) 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 dThe 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));
end
out(i) = temp;
end% in case of base 2
out(1:20)
out(2:2:40)
out(4:4:80)
% in case of base 3
out(1:20)
out(3:3:90)
out(9:9:180)
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,
Alberto
*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.
https://soundcloud.com/albertoz/praelude-for-a-robot
You do not have the required permissions to view the files attached to this post.
Last edited by AZZIN on Wed Mar 04, 2020 9:24 pm, edited 2 times in total.
-
- KVRist
- 123 posts since 25 Jul, 2004 from Italy
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
. 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
.
Alberto
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
. 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
. Alberto
You do not have the required permissions to view the files attached to this post.
-
- KVRian
- 698 posts since 7 Dec, 2009 from GWB
Nice to see your work posted here AZZIN. Cheers!
-
gentleclockdivider gentleclockdivider https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=203660 - KVRAF
- 6110 posts since 22 Mar, 2009 from gent
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
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
Soul calibrating ..frequencies
-
gentleclockdivider gentleclockdivider https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=203660
- KVRAF
- 6110 posts since 22 Mar, 2009 from gent
A handy channel sequencer with gate +velocity lanes , making it verry easy to see different drum channels
Step length per sequencer for polymeter and time division for polyrytm
Load as many as you want ( it's a macro fragment , not a project file ) , just change fill colour per instance .
Step length per sequencer for polymeter and time division for polyrytm
Load as many as you want ( it's a macro fragment , not a project file ) , just change fill colour per instance .
You do not have the required permissions to view the files attached to this post.
Eyeball exchanging
Soul calibrating ..frequencies
Soul calibrating ..frequencies
-
Obsolete485692 Obsolete485692 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=485692
- Banned
- 42 posts since 26 Dec, 2020
Hi,AZZIN wrote: ↑Wed Mar 04, 2020 9: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
Why not using the LUA scripting for implementing this? That would have been easier, but with less fun.. Comments, feedback, anything, welcome. Enjoy
Alberto
firstly - thnx 4 sharing really elaborated stuff.
If this was meant for programmers/ mathematician or it is kind of secret sauce I am sorry to ask – since specially for programmers figure thing out in stand-alone mode is basic attribute.
If it was meant for regular electronic music guys (spoiled by kinder-garden manuals) if I can kindly ask for more indices how to connect fragments to final midi output.
A-linmap is supposed to go to set key, should not be there some pack note module too - something like in pic bellow (but like this it is obviously wrong))?
Can it be routed to midi output - is not it just for modulation, I saw in print special ratios suited rather for scala tune files than keyboard.
PS: Reset, INIT, step - are Signal modules, right?
Cheers.
Jiri.
Last edited by Obsolete485692 on Sat Sep 25, 2021 7:55 pm, edited 1 time in total.
-
Obsolete485692 Obsolete485692 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=485692
- Banned
- 42 posts since 26 Dec, 2020
-
Obsolete485692 Obsolete485692 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=485692
- Banned
- 42 posts since 26 Dec, 2020
..
-
Obsolete485692 Obsolete485692 https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=485692
- Banned
- 42 posts since 26 Dec, 2020
Thanx - this is real fun and with less steep start.AZZIN wrote: ↑Wed Mar 04, 2020 9: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 (https://reglos.de/musinum/) 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):
Please note the colums 2nd and 4th: here we have a "self-similarity" effect, which is a very interesting property of the output series.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
The architect implementation implements the following (Matlab/Octave) code (with some limitations):
Now, if you have Matlab/Octave on your computer try the following: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)); end out(i) = temp; end
% in case of base 2
out(1:20)
out(2:2:40)
out(4:4:80)
% in case of base 3
out(1:20)
out(3:3:90)
out(9:9:180)
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,
Alberto
*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.
https://soundcloud.com/albertoz/praelude-for-a-robot
I also see here a-linmap connected, so I guess it should maybe work kind of similarly for a a-clifford etc.
