L-system iterations
Hi everyone,
here is an abstraction to do L-system iterations as described here: https://en.wikipedia.org/wiki/L-system#Examples_of_L-systems
The rule sets are loaded from text files, and the iterations can also be saved to text files. I'm not sure what the possible uses of this are, and it gets pretty slow as the strings get longer, but it was fun to do.
yay!! I had a quick look and this is just great! I can't wait to test this for real, change the rules and stuff.
it is true that it is a bit cpu intensive, but in an odd way. for example, pd's "load meter" patch doesn't show much increase in cycles, but in my (windows) task manager I can see the cycles increasing with the number of processes pd is running. iterating very slowly allows me to get further before pd starts freezing, and cpu gets into the 90s.
I wonder about implementing a sort of setable "loopback" in the iterations, where from a user-defined point a specific branch is chosen and iterated again from the beginning. That way one could grow the system, iterate through a chosen number of generations for some user-defined purpose, and then chose some segment of that output as a new starting point to run the process again from the beginning.
@Coalman Thanks for the feedback. I think it's "cpu intensive" in a different way than audio dsp which is sort of a constant load, here is more of a peak as far as I can tell and might be because the lines grow exponentially with each iteration and there are a lot of elements to parse, so perhaps that's why the cpu needs more time.
This stuff is all new to me so I'm just trying to figure out how to implement some of those algorithms I see around, and see if there's a use for them. Here I found some good explanations of the various types of L-systems: http://www.modularbrains.net/support/SteliosManousakis-Musical_L-systems.pdf
The non-propagative systems seem very interesting too.
With regards to your suggestion about "setable loopbacks", do you mean to have the ability to pick two points in the string and use the portion contained within as the new seed for the next iteration? Perhaps this could be done by doing iterations element-by-element rather than string-by-string.
One thing to point out is that, as far as I can tell, if you put a string within brackets for example, that string will effectively become a branch with brackets as delimitators (and will have sub-branches defined by sub-brackets). The fractal_tree example in my patch is an example of this. But maybe what you are suggesting is to export the different branches, or somehow isolate them. Am I correct? It's interesting, I'll think about that.
@weightless I like this idea of bracketing strings (I like the visual language too). I guess that the brackets as delimiters would behave as part of the generating shapes that seed further generations propagated from that point. the thing is, if the L system is iterating something with simple fractal rules like a cantor set, and this is deterministic and the rules themselves don't change over time, an isolated branch would be then similar to another piece from a lower order of magnitude anyway. a segment of a future generation will be a segment of the generative string in the first place, just "out of phase" (in a different order due to a different starting place). so, in that sense it is like what I was trying to get at before, a loop where you could run the process to some level of complexity then return back and do it again. I guess that is actually not at all a hard thing to do, I was just excited by the way you implemented this, super great.
this website might be of interest: http://algorithmicbotany.org/
there is a whole book in pdf on there about generating fractal plant morphologies with L-Systems
@Coalman I agree that more variation and controls need to be implemented. As far as I'm concerned the way the patch works right now is kind of useless because, like you say, for each set of rules the generations are always the same, including the branches. It's all predetermined in the rules. This hasn't got many useful applications as far as I can tell, also because you either pre-iterate the system to some level of complexity and then work on the result of that, or the process gets too slow by the 20th-ish generation anyway, even with the simplest of rules.
I will surely look into ways of implementing some sort of variation, like feedback from the outside, stochastic rules and so on. But I'm also happy that it works as it is now in it's simplicity.
Thanks for the link, I haven't got round to reading "The Algorithmic Beauty of Plants" yet but there is so much more stuff in there too. Will dig in asap.
@weightless very nice. i didnt knew the lindenmeyer sytem before. but i like the idea to create something like lindenmayer trees for sequencing music. but first i have to understand it better .
This one does the non-propagative iterations, similar to a cellular automata. I haven't tested it with other rule sets yet, but it seems to be working fine with this one.
EDIT: updated the description in the help file.
i tried to implement the lsystem_np into the pixelgrid sequencer. i thought the pixelgrid is more suitable to visualize this kind of pattern. when i saw the "visual decision trees" i was also thinking if it could be useful to put instead of polygons arrays into arrays for some iterative things. i have to admit at the moment it looks nice but sounds a bit repetitive. perhaps i also have to rethink how to sequence those patterns.
pixelgrid_sierpinski.zip
@weightless Great work @weightless.
I have no time to delve into this, but a few small ideas.
I wonder whether an array would be faster than [text] and so speed up the recursion, although values would have to be translated to integer representation for the array (and the rules)..
Also, there was some work done for Gem (extra/Gem/examples/13.recursion) in extended, that is interesting. Suggestions were for doing transformations within the recursive loop to break repetition, and also "popping" the stack, both of which could be triggered through rules or randomly.
David.
@Jona Nice! I was also thinking that this type of system is more suited for a fixed-step kind of sequencer, but you're right it's pretty repetitive. Perhaps here also some kind of randomisation or offset would be helpful to introduce, but playing with the rules might help as well, for example in the patch I posted, if you change the rule "tail -" to "tail +", there's already some variation introduced.
@whale-av Thanks for the tips. Is there a reason why array would faster than text? I thought that text loads the file into a buffer as well. If you think array is faster, it might be worth trying for sure, I didn't think about that and just went for the convenience of (among other things) being able to use [text search] so the rules don't need to be in any particular order in the text file.
Re. the gem examples, that sounds very interesting indeed. Is there a way I can get those examples without having to install extended?
@weightless Array faster than text has been suggested before, but I do not "know". Just a maybe.
Here is the folder. Obviously will not work without Gem (or zexy or?), but the thinking and some patch representation of it will be there.......recursion.zip
PS.... I also found that the recursions were much faster if not printed to the terminal.
David.
@whale-av Thanks! I will have a look and also try with array and see if there's any difference.
Here is a a small update on the non-propagating one. The head and tail can be set to "loop" in the rules, so for "head" this means that the first element takes its left state from the last element of the previous iteration, and for "tail" it means that the last element takes its right state from the first element of the previous iteration. This already introduces some pretty funky variations.
Simple runner to show the "loop" concept.
@weightless i tried to run the runner algorhytm over the grid from the sierpinski loop algorhytm. a lot more variation, i dont know if it sounds too random. 2lsys.zip
@Jona Very nice!
now both algorhythms have their original pattern. a note is only played if both algorhythms are on one field. different colors from the runner algorhytm represent different midi channels. lsys2b.zip
This is an updated version of the patch that accepts multiple production rules for each predecessor, which are picked randomly every time according to weights. More info and an example inside the patch.
EDIT: updated patch
@Jona This is an excellent idea to combine two patterns. Great stuff. Here is a variation of the sierpinski in place of the runner.
@weightless good idea to take the sierpinski 2 times. i modulated the reset of the iterations differently and use different sounds for different colors (i need to clean up the patch when i have time...): 2lsysd.zip
Oops! Looks like something went wrong!
