This is such an interesting idea to me, both as a patch performer and a plugin developer.
As a performer, I like how each of the modules by itself has a clear and direct purpose. I like how they can be combined in an unlimited number of creative ways. And I love the visualization of what’s happening in Depict. It feels like I can focus more on creativity, without having to study the modules for an hour before I can start doing anything interesting. And I can always see what’s happening. That’s incredibly valuable to me because I’m a visual thinker.
As a developer, I love the use of extender modules not as optional accessories but as the primary way of getting things done. I have often thought in terms of designing chains of adjacent modules to optimize a left-to-right signal path without cables. This is different in that the readers/writers have no explicit signal flow direction; I suppose everything reads/writes the memory in whatever order their process functions are called?
I imagine if you have multiple Embellish connected to Memory that you might get inconsistent results if they try to write to the same sample of memory at the same time. Is this correct? I know that’s an edge case; most of the time the writes could happen in whatever order and the result will be about the same.
Thanks, @cosinekitty, and yes, two Embellish’s writing to the same point will, mmmmm, produce a noisy blend, no doubt of interest to someone.
I considered using messages instead of just sharing the same pointer, but messages appear to have an inherent latency to them (one sample per module to module movement). So yes, the process calls come in what ever order they like.
I was hoping that something like this would appear, and tried to pitch the idea once
The only thing that is missing from making this perfect, would be to be able to move the read head freely, allowing scratches, slowdowns, speedups etc… and some good interpolation/anti-aliasing.
Also it might be really useful to be able to set the buffer in multiples of a clock, to sync it to BPM.
If I remember correctly, @baconpaul said all this could be done easily with his universal delay buffer from the Surge XT stuff, he even wanted to build that, but is probably very busy with everything else he’s doing. Maybe you can use his technology, though, to make this thing fly af.
He said he got the buffer ready for all that, perfectly interpolated, so maybe you can plug it into this thing. I’m no programmer, but I hope this might just work
It looks like a cubic interpolation. That’s what my old SFZ player does. I know for a while there were people doing “zero order” or “drop sample” interpolation, and everyone agreed that sounds bad. It’s not clear to me how audible the differences are once you are at least at linear interpolation. I’ve always done cubic, but that’s more a habit than anything else. I know some people make some pretty fancy polyphase since interpolators…
I was hoping it could be done so that the modulation would sound as smooth as using the adjust slider, allowing to scratch the sample, create slowdowns etc.
TIME1 is the first open source plugin that can do this the same way as Gross Beat, MRhythmizer, Time Shaper… in those plugins you can control the buffer very precisely with an MSEG - if this could be done with external modulators in Rack, this could be really powerful.
But I have no idea how to do it… I just have some ideas how you could use it if it would work
Without trying Time1 yet, have you noticed that there is a speed input that gets added to the speed control? If not, that might open up some possibilities.
I liked that V/Oct idea so much, it’s coming in 2.0.15 (whenever that happens).
Here’s a demonstration video, I think it opens up some interesting uses. Like a…janky Mellotron whose sound changes as you play it.
By the way, I’m posting irregular progress reports on my modules at my StochasticTelegraphTech YouTube channel, in case you’re interested in following along (or suggesting ideas that escape me).
2.0.15 release is out this morning. Here are my release notes:
Memory gained access to the file system:
Memory can now load .WAV files into itself, replacing the entire contents of the Memory and resizing it.
Memory can save .WAV files as well.
Since file operations can take a widely varying amount of time, Memory sends out a trigger when those operations complete.
You can load and save files from the menu, or you can use BASICally to send Tipsy text messages to Memory to tell it to load or save a file.
Since surprising things can happen when loading or saving files, instead of silently failing,
when you have the LOG output of Memory cabled to a TEXTn input on a TTY module, you can read the log of what happened on the TTY.
Fade on Move - affects the behavior when the slider or SET moves the position of the head.
If checked (the default), the L&R outputs will be silent until the position stops changing. If not checked, then the playback will continue as it’s being moved.
See example video.
Use Speed as V/Oct - affects how the SPEED is interpreted. When unchecked (the default),
the sum of the SPEED input and control is how many samples the playhead moves forward per sample emitted, so 1 is normal speed, .5 is half-speed. When checked, this sum will be interpreted the way that V/Oct is interpreted in most modules. See example video.
When the sliders on Ruminate and Embellish are released, they now resume normal operation more quickly.
Put a big “T” behind ports only input or output Tispy text messages. Put a less solid “T”
on the BASICally OUTn ports, to suggest that they can emit both Tipsy and regular values.
