Great, I will test the new build asap,
just one idea that comes to my mind,
would it be possible to add an option to mute
“steps” between two markers ( best without audible clicks)?
why would you ever be concerned about using markers set for one sample on another? I can’t imagine ever needing that.
for many reasons. Try it
Hi everyone,
Just a quick update:
(here’s dark view for a change of pace)- I spent a few days improving mouse input for dragging the playhead. It was a little bit broken before, and it’s a lot smoother now!
- I added the option to loop sample playback.
- The library view looks pretty now
- I added waveform computation caching. The module is extremely lightweight.
- I added a menu item for locking all mouse interaction on the waveform widgets. This prevents the module from interrupting normal rack usage. Previously, if your mouse just happened to be hovering over the module and you tried to pan or zoom rack’s interface, my module would hoard those events.
- I fixed a bug where double-clicking on a marker (which removes it), then attempting to drag said marker would crash rack.
Next up:
- Research menu item for automatically setting markers
- I’ll need to go back and adjust some code in Autobreak Studio which shares some common waveform rendering code with Cue Research. Nothing major, and nothing that will change Autobreak Studio.
@rsmus7 I don’t think I’m going to add that “mute” feature, because… couldn’t you use the first marker output to trigger a 3rd party external module to mute the output? Unless I’m not understanding properly. Anyhow, I’m hoping to launch fairly soon with a minimal set of features, and maybe it will grow over time?
Here’s the newest build, which should be ready for release:
The cue module is extremely cool! Thank you, there are plenty of creative ways to use this one, I’m sure (I need to try it as soon as possible, hah!)
One suggestion: it might be very powerful if this included an expansion module with a trigger layout like the trigger outs currently, but with trigger inputs. When receiving a trigger, the sample playback would jump to the corresponding marker, on the fly. (There could also be a switch on the expansion for "still send marker’s trigger from the corresponding output, too, when jumping.)
One could then chain several of these Cue Research modules, driving the playback position jumps in some other sample with the markers of another. All sorts of wild playback schemes come to mind. To refine, maybe some adjustment parameters for the specific way the jump happens (i.e. instant jump, faded jump with previous position fading out while starting instantly from new position, crossfade jump with fade in/out, blabla. And so on. Wahh. Got too carried away, but the core idea of trigger inputs controlling jumps to markers is imo a solid one! :))
Hi Guenon! I couldn’t agree more! I’ve been thinking about the same thing. Well… sort-of the same thing. I really like the idea of being able to set jump points to control sample position, but not necessarily as an expansion module, but as a completely new module.
Something like this:
Would this be flexible enough for what you’re thinking of? Each input would have one single corresponding cue marker – unless each input was muti-channel. Ha ha ha.
I like the fading idea too. I think that I can pull that off.
I’ve also thought: Maybe I can make a module similar to Akai MPC hardware. If I did, it could be my first commercial module? This would be separate from the Cue Hopper™ module. (Not really trademarked, but I like the name!)
That’s very clean! It’s a stylish counterpart to the cue trigger out version, to have such a trigger-input-jumper module :), I agree.
The reason why I thought of an expansion module for adding jump triggers to the Cue Research module was the ability to chain the modules together. Having both in and out triggers working in the same module, and the triggers interacting with the same sample playback situation, has interesting implications.
Then you can for example self-patch ad-hoc loops (and activate/deactivate them by muting the connection) by patching a trigger output from a marker occurring later in the sample into the trigger input of a marker happening earlier in the sample. Also, you can also patch trigger outputs into the inputs of another Cue Research, with some other sample, with markers in different places, and patch the output triggers from there back into the jump trigger inputs of the first Cue Research. All sorts of controlled or chaotic chains become possible.
In both the self-patching and chaining multiple Cue Research scenarios, it’s possible to insert some other modules to alter / randomize the route of the triggers, changing the trigger input they activate (and also when they activate it, adding variable delay paths as well), letting you put into motion a varying playback position monster that constantly plays back varying sequences that self-trigger … If you allow for longer fades, this might be interesting for ambient soundscape uses, too, not just “jumpy” stuff.
Hmm. Let’s think it through. Maybe it would work like this:
- If the expansion module is connected, then the user can select an input rather than an output. When that’s the case, setting a marker will set a jump point for that input. There can be only one marker (jump location) associated with each input.
- Input markers would be separate from the output markers, and they’d have a different color (like red) instead of blue.
- When an input is selected from the expansion module, any selected output is de-selected. (And vice-versa)
I think this makes sense, but let me know what you think.
(I’m secretly really excited about your idea, mostly because you sound excited about it!)
This would be awesome imho,
and I’m exited too
Yep, awesome! Having a full, separate set of input markers does have its benefits. Of course it’s also a bit of added complexity managing both input and output markers, hmm. But it sounds really flexible. (What I imagined was, just having one set of markers, where each marker can automatically have both an input and an output trigger jack associated with it, if the input trigger expansion is attached. So you can both send triggers from and jump to any marker you have placed.)
That could also work! I may be able to support both strategies through a context menu item. I’ll know more when I start digging into it. I see the benefit of being able to place a single marker while specifying both the input and output. Otherwise, you could be in a situation where you’re trying to place two markers directly on top of each other, and the interface may make that challenging.
Also, on a side note, I might add the ability to “select” a marker, which could allow the user to change the marker’s assigned input and output. It might be frustrating (and easy to forget) to set both the input and output before placing a marker.
I may have time to work on this within a few days. @jue Also had some interesting ideas for an expansion module, which has to do with setting loop points. I might combine both into a single expansion module.
Here’s the Cue Research expander design (WIP):
Loop Control
- Additional control over loop points, which are not snapped to any specific cue locations. However, as one would expect, as playback hits any cue locations within the sample, the associated output will trigger. (Includes CV loop point control and attenuators)
- A separate reset for jumping playback to the loop start
- Dedicated trigger outputs for loop start and stop (at the bottom of the expander)
- Looping is enabled/disabled in the context menu, which is already in place
Input Cue Hopping
- Specifics are still pending, but generally the idea is that you can jump to a specific cue position by providing an input trigger to one of 32 trigger inputs.
Wow, this looks super cool and polished already!
I think it would be really useful to have a “next” input trigger, which jumps to the next marker, at the final marker if you send a trigger it goes back to the first marker.
Sure! I’m happy to add that feature to the expander. Also – not “previous” as well?
wouldn’t say no to previous either!
Just a quick note that I’ve exhumed the Satanonaut panel as a blank panel. The artwork is highly compressed and lost a bit of its detail, but I hope it’s a reasonable solution for those who have missed it so dearly.
Quick shout out to Kirt Burdick for his original artwork. He’s now 5 issues into his newest comic, “Death of Power”, which has been widely acclaimed as more historically significant than “On the Origins of Species”, “The Wealth of Nations”, and “1984” combined!!!
I like 1000 times v 2.25.0 with all my respect this is not the same
Hi @jerezsurfboards, I understand. The detailed panels were causing issues for Cardinal (specifically for the web version). Besides that, simplifying the panels makes it easier for me to extend and maintain the collection, which is important for me personally. Currently I have to devote more time learning new technologies for my career and, unfortunately, less time on rack modules.
But I’d love to hear specifically what you miss about the old panels and designs. Perhaps I can attempt to revive some of that magic for you.
Thanks,
Bret
More on the simplified panels…
I may be sounding defensive. Spending a lot of time on a subject like this often points to some defensiveness or hidden insecurity. In my case, probably insecurity. Ha ha ha.
I’m dwelling on this not to refute others’ opinions, but rather to explore my own reasoning. It’s quite possible that I made a bad call by simplifying the panel designs. Maybe it would have been better to continue to evolve the more detailed panels since most people were fond of them.
The impetus was certainly Cardinal’s inability to port over my collection gracefully. But there was more to it.
At the same time, I was inspired by a YouTube channel called “Continuous Delivery” where Dave Farley suggested that good software is software that works, and that’s easy to change.
The ability to change software easily, safely and with confidence is a marker of its quality.
This idea of “easy to change” really resonates with me. It’s something that I’ve loved about the rack fundamental modules: They’re so simply written and easy to understand! I wanted to make my collection more like that.
The panel work for modules was quite time consuming. Creating a new front panel (both light and dark versions) took about a full day of work. That might not sound like much, but it adds up. Making modifications was also time consuming.
So I decided to simplify the panel designs.
In addition, I spent a few days modifying the widget placement code so that I could simply move elements on the front panel, and the corresponding widgets would move accordingly.
Finally – I’m thinking ahead to when AI will be doing a lot of this work for me. By streamlining my code and panel creation, it should be easier for AI to share more of the work.
Anyhow, thanks for listening.