Is your feature request related to a problem? Please describe.
I would like to be able to feed tidal patterns back upon themselves, making patterns whose output is dependent on their past or current output. Feedback can lead to chaos and interesting generative capabilities. It also models interesting things in nature and human experience.
Describe the function/feature you'd like
Perhaps it could work similarly to feedback in Hydra. In hydra I may reference an output in the algorithm defining the output. For example, to create a picture that forms serepinski like fractals I can write the following: shape(3).blend(src(o0)).repeat(2,2).out(o0) where shape makes a triangle, blend mixes the output pixels with the triangle, and repeat tiles the page with copies of the original image. (you can try it for yourself here: hydra )
In tidal, perhaps we could create a pattern that references one of its parameters in defining that parameter. For example, we could define a pattern of notes that is defined in part by a modified copy of the previous notes. d1 $ note ((flip mod 24) . scale "major" $ "0 2 4 5" + (slow 2 $ src 1 note)) #s "gtr"
In this imagined pattern the src function could reference a parameter on a running pattern bus, in this case d1, and use it as an input.
In this way we could also more easily describe algorithms where we make decisions about what the next part of the pattern should be based on the prior output.
Describe alternatives you've considered
I have considered creating a feedback loop in midi to accomplish this where midi control is routed back to tidal by Jack or some other midi manager.
I have also written functions that make reference to past state but which rely on recursion. (for example soak or snowball). These functions, due to the pure functional recursion need to take a parameter to limit the recursion depth to prevent infinite looping. This prevents the feedback from being as free as I would like and causes unwanted repetition.
Additional context
I want to recognize the difficulty of doing something like this both from an implementation point of view and a design point of view. It may be very easy to create code that crashes tidal while playing with these concepts.
Is your feature request related to a problem? Please describe.
I would like to be able to feed tidal patterns back upon themselves, making patterns whose output is dependent on their past or current output. Feedback can lead to chaos and interesting generative capabilities. It also models interesting things in nature and human experience.
Describe the function/feature you'd like
Perhaps it could work similarly to feedback in Hydra. In hydra I may reference an output in the algorithm defining the output. For example, to create a picture that forms serepinski like fractals I can write the following:
shape(3).blend(src(o0)).repeat(2,2).out(o0)where shape makes a triangle, blend mixes the output pixels with the triangle, and repeat tiles the page with copies of the original image. (you can try it for yourself here: hydra )In tidal, perhaps we could create a pattern that references one of its parameters in defining that parameter. For example, we could define a pattern of notes that is defined in part by a modified copy of the previous notes.
d1 $ note ((flip mod 24) . scale "major" $ "0 2 4 5" + (slow 2 $ src 1 note)) #s "gtr"In this imagined pattern the
srcfunction could reference a parameter on a running pattern bus, in this case d1, and use it as an input.In this way we could also more easily describe algorithms where we make decisions about what the next part of the pattern should be based on the prior output.
Describe alternatives you've considered
I have considered creating a feedback loop in midi to accomplish this where midi control is routed back to tidal by Jack or some other midi manager.
I have also written functions that make reference to past state but which rely on recursion. (for example
soakorsnowball). These functions, due to the pure functional recursion need to take a parameter to limit the recursion depth to prevent infinite looping. This prevents the feedback from being as free as I would like and causes unwanted repetition.Additional context
I want to recognize the difficulty of doing something like this both from an implementation point of view and a design point of view. It may be very easy to create code that crashes tidal while playing with these concepts.