I share your concern about scroll speed, but I’d appreciate slower scroll speeds. It would be nice if we could both be satisfied with the scroll range, but can it be extended? If so, how much precision will that sacrifice? I don’t know. Perhaps there’s a simple solution, like a mode that cycles thru a set of ranges. Perhaps something even simpler. Perhaps we’ll all just Diver’s scroll ranges and work with what we have. I don’t consider this to be a high priority when we have a number of bigger problems. Perhaps we should discuss this again, after the firmware update? I don’t want to delay solutions to more urgent issues than scroll speed range. I think the firmware update we’re discussing here will be big enough, but I’m certainly not dismissing anything. Far from it!
scroll speed would be a great setting to be able to fine-tune for user preference if (and hopefully when!) a Diver firmware manager becomes available. would love to see user-tweakable ranges, response curve and/or slew options like we see in the Memory Palace firmware. could be neat to have Diver’s scroll speed very subtle and responsive near the middle of the range for ultra-slow scrolls with more drama and acceleration at the further extremes!
I will second the request for slower scroll speeds. I find the slower ranges to be much more usable in a patch than the fast ones. That and more ramps are at the top of my personal list.
Also agree that the option to dramatically reduce the scroll speed would be useful. In scrolling patches, I am regularly just trying to get the sliders just close enough to the middle that they move but don’t stop. More range on this would be great–something like the walk, jog, run options on Memory Palace?
We’ve got a ton of buttons and LEDs on this thing. So different types of boot modes or ranges should be pretty easy to do. If you don’t mind an “Advanced Function Guide” that involves some combo buttons or long presses, we could enable a config menu that uses the LED bars. Something like range is easy. This becomes more practical once we have settings permanence thru power ups.
How fast do you want the scroll to go? If you go at frame rate, the ramp never moves, so a 1:1 strobe is max speed – and somewhat useless – so how many frames-per-repeat would be reasonable for max speed?
FWIW, I think we can give the scroll whatever range we want – and I can apply an expo curve so that it feels natural rather than weighted. Really I just need to know what frequencies I’m shooting for, when it comes to minimum and maximum points in the range.
I think an Advanced Function Guide through long press/button combos is a great idea! I’d like to see scrolling speed as close to frame rate as possible. I always love the resulting textures when things are not quite frame rate, but appear to be moving slower than they are. I’m terrible with what the actual numbers would be, so hopefully I’m explaining it well. I don’t utilize speeds much slower than what Diver already preforms, so hopefully someone else has something in mind in that regard.
Yes, exactly – our desktop app has dfu-util packaged in, and once I get that released it should be just a matter of clicking the “download Diver firmware and update” button. The app is a Qt app cross-compiled for MacOS, Linux and Windows. I just need to find a week to work on it after we ship our current projects.
The weirdest thing about Diver, for me, is that the ramps are the wrong shape. Well that and the vertical line discontinuity 2/3 of the way across the screen from the left.
All of the ramp shapes have squared off sides.
The circle has square edges. So does the diamond and the expo diamond.
If you key them down, they get more squared as they get smaller.
I’ve never really noticed anybody discussing this before.
I don’t know if it’s because my system is PAL.
The images are a keyed triangle ramp and a keyed circle ramp.
The weirdest thing about Diver, for me, is that the ramps are the wrong shape. Well that and the vertical line discontinuity 2/3 of the way across the screen from the left.
OK, that’s definitely an issue to look at! Are these outputs coming directly from the H+V and H-V? Or are you sending the H & V elsewhere (like Shapechanger) to make the shape?
These modes on Diver weren’t intended for shape generation that wasn’t also kind of abstract and under modulation from audio, but I can see why you’d want to use them this way. For shape generation you ideally have a quadrilateral high gain function (ramp cropping, like Shapechanger and Chromagnon) if you are wanting to make the shape bigger or smaller. So maybe we just need some “clean shape modes” where you have Shape Width + Height on the sliders instead of the phase. Or some fixed size hard shape output modes, as mentioned above.
If that IC can’t be convinced to do HD timing, would it be possible to have Diver in a SD sync / encoder setup, take the encoded output into TBC2 or Chromagnon to upscale it to HD and then process the decoded RGB outputs from there? Obviously that’s taking an expensive route to accomplish this but just wanted to make sure my thinking on this was correct as it’ll be the same principle for any modules that are firmly stuck in SD.
Yes absolutely. I can’t really speak to everyone’s setups, but if you have a large system already, and you like it the way it is, and don’t mind starting a separate system for HD, then this might make the best sense. Keep the Diver in SD system. Use the SD system to generate it’s own output image. Feed that image into the HD system via an upscaler.
Chromagnon will be lots of fun if you just want to experiment with this, since it can be its own “HD system with upscaler” in one box. So you can use it like an output amp/upscaler/post processor for your SD system, and try out different upscaling resolutions, without changing anything in your existing system.
Ultimately the different resolutions are just tempos. Some of you may like the existing “feel” of NTSC/PAL timings. The signal path itself is gonna be the same in both SD and HD systems. With HD you are just sampling it a bit deeper, when you end up recording the output. And that’s going to change the feel.
TBC2 has a built-in upscaler as well, right?
It has two of them, yes! With deinterlacers for interlaced/progressive conversion too. Patch in pretty much any analog video source (HD, SD, component, composite, VESA RGB in a few resolutions, etc) and you will get 1V RGB output scaled (down or up) to whatever your desired output / sync generator mode is. If the input format matches the output format (like NTSC to NTSC) then the scaler is bypassed.
Is it possible to make Diver’s trigger input respond to faster incoming triggers? I find that it has a tough time keeping up with lots of trigs (like regular 16th notes at 100+ BPM), but maybe that’s just a limitation of its more digital nature.
Would it be possible to map the trig input to switch between banks (and/or anything else, really)?
And yeah, I’m definitely here for faster + slower scroll speeds too
Yeah. Great idea. I can move sampling of the trigger to hsync interval instead of vsync interval, so it will check each line if the trigger has changed states, instead of each frame. Any trigger less than 33ms right now will be a little short.
Would it be possible to map the trig input to switch between banks (and/or anything else, really)?
Yep. I’ll think about how it would work from a UI perspective, but let me know if you have any ideas.
And yeah, I’m definitely here for faster + slower scroll speeds too
How slow do you want to go? At the lowest speed, how long would it take to scroll around one time?
To map the trigger to move between banks, maybe holding MAP + BANK SELECT makes the strip of LEDs flash affirmative, i.e. mapped? If it were somehow possible to select different banks with different CV values (based on v/oct, gate length, or something else), that’d be really neat too.
Slow: maybe about a couple of minutes for a full scroll? Fast: can it get really fast, like into audio-rate speeds?
I don’t think I can do that via the trigger input, but I will check my pinout to see if I have an ADC pin there. Some sort of “ramp shape scrambler” based mode though, where you are controlling the waveshape from one of the two CV inputs, is a possibility. Or a curve function (like Shapechanger/Chromagnon.)
We need to have some kind of chart to identify these new modes. Maybe a single 3x5 card “user cheat sheet.”
It would be nice if we could both be satisfied with the scroll range, but can it be extended? If so, how much precision will that sacrifice? I don’t know. Perhaps there’s a simple solution, like a mode that cycles thru a set of ranges. Perhaps something even simpler. Perhaps we’ll all just Diver’s scroll ranges and work with what we have. I don’t consider this to be a high priority when we have a number of bigger problems. Perhaps we should discuss this again, after the firmware update? I don’t want to delay solutions to more urgent issues than scroll speed range. I think the firmware update we’re discussing here will be big enough, but I’m certainly not dismissing anything. Far from it!
