Diver Firmware

Category: Forum · Tags: diver, eurorack · Posts: 152

#1 — creatorlars · 2021-08-27

Let’s discuss issues and features with the current Diver firmware, and what you would like to see in a bugfix oriented firmware update soon.

On my own list of issues to investigate:

1. Sync robustness. I have had several reports of an intermittent “blip” that occurs in the waveform at longer, but random intervals (1-2 minutes apart). I can see and confirm this issue here as well. I have a few solutions to try.

2. Texture wrapping / scanline discontinuity. Improvement here may not be possible without a hardware deinterlacer, but there may be some things I can do to improve waveform discontinuity between lines through some more aggressive interpolation. Or I may just have some math wrong! Or it could be related to issue #1. Some investigation is needed.

Threads related to issue #2:

Sure! It would be helpful to have everything in one place.>

1. More ramps. Easy stuff! The same library code will power these ramps as the ramps on Chromagnon and TBC2. A VCO mode and new pseudorandom/FFT modes would be in this category too, but we’ll just have to see how fast the other issues get solved.

2. Non-standard syncs. Diver is currently an NTSC/PAL based device, using an IC that is designed for NTSC/PAL input only. This makes it potentially difficult to integrate with new HD sync generators like Chromagnon and the Gen3 encoder module. I want to see what, if any, ability the TVP5150AM1 has to detect or PLL lock to non standard timings. Since the TVP5150AM1 doesn’t actually generate the video itself, and the STM32F4 system is running on its own clock PLL, there may be some workarounds we can investigate.

3. ADC/noise performance and “flickering” issue. It looks like we’re getting a little value jitter in the phase CV input. I need to add some better filtering to the code. This issue may be different in different case power scenarios, and I do not believe it relates to issue #1.

Threads related to issue #5:

I’m seeing noise on edges and some phase (?) jitter. I’ll be very happy if a firmware update fixes this. >           >  > Here’s a second video, using a different Diver output and some keying. You can see  the noise more clearly, I think.>

1. Settings permanence across power ups. I have working code for this already, using some of the internal flash as an EEPROM. So I think we can make this happen, no problem.

And that’s about it. What else? My ongoing assumption is that issue #1 is the primary concern of users with the module as it is. Please let me know if that is not the case.

#2 — vhsdestroyer · 2021-08-27

Does issue #1 also refer to the sort of “seem” in the video field as well? I’m sure you’re aware of the issue I’m talking about, though, the exact way to describe it is lost on me at the moment.

#3 — sean · 2021-08-27

This issue, right?

I received a Diver in the latest (December 2019) batch which works well, but all ramp patterns show a “seam” running vertically at a constant position, about 3/4 of the way across the screen. It appears with any bank selected and its position is unchanged by any panel controls. It is most obvious for vertical ramps but also visible with H+V or H-V outputs if you’re looking for it. > I see the discontinuity when using Visual Cortex, Cadet II, or Memory Palace as output encoders, with multiple disp…>

#4 — saiteron · 2021-08-27

not sure if hardware supports it but i would love to see Diver remember settings between power cycles. really this is the main weakness of the current firmware for me! beyond that i’m looking forward to the remaining slots getting filled up with cool stuff and/or being able to fill them up with things myself.

#5 — rempesm · 2021-08-27

I hope that HD sync will be possible but really my main issues with using Diver right now are the one to two pixel seam mentioned in Sean’s post and losing my settings with every power cycle. Having the module always save settings on power down would make it less of a hassle to get back to where I was in a patch.

More ramps to fill out the banks or even the ability to add our own gradients would be lovely.

Is the oscillator mode/bank still a possibility?

#6 — creatorlars · 2021-08-27

Thank you all – I added a couple more items to the OP list if you want to go over it.

#7 — vhsdestroyer · 2021-08-27

yes, exactly what i was talking about

#8 — creatorlars · 2021-08-27

rempesm wrote:

More ramps to fill out the banks or even the ability to add our own gradients would be lovely.>>>> Is the oscillator mode/bank still a possibility?

These kind of features should be easy to add, and part of item #3 in the OP. I can also open source the firmware once we are at a stable release.

Some sort of simple “ramps shader scripting” thing may be the way to go long term.

#9 — nerdware · 2021-08-27

5 still bothers me. Perhaps I’m in a minority here, but the noise problem makes keying Diver output impossible. It greatly reduces the utility of the module. That makes it easily the most frustrating module I own. It’s so bad, I’ve considered selling the module.

I don’t own a computer that can run the firmware updater. So I’ll have to buy a device that can do. It’s unlikely I’ll have any other use for that device, so I’m seeing this module in terms of the Sunk Cost Fallacy. I could spend money to make it usable or I could just sell it with a warning to the buyer. So whoever buys it can run the firmware updater.

That’s the main reason I’ve kept the module this long. It has some small value, but nowhere near enough to justify the space it occupies in a system I can’t expand. Either I sell my Diver or I sell another video module. So when the new firmware is available, that’s likely what I’ll do. The buyer will have to trust that update will work.

Of course, if I try selling it and nobody buys it, my only option will be to keep it. I could trust that the new firmware will justify purchasing a device that will run the updater, but it’ll be more sunk cost. Perhaps it’ll pay off, avoiding the fallacy part.

Obviously I’m very unhappy with all this.

#10 — creatorlars · 2021-08-27

nerdware wrote:

Obviously I’m very unhappy with all this.

Yes, I’m not quite sure I’m following you. I wasn’t under the impression anyone found the module unusable as it is – just that we have a few quirks to clean up. I’m very sorry to hear your experience with Diver has been a disappointment.

On output noise:

I don’t have keying noise in the issue list at all. Is #5 (ADC performance, phase displacement jitter) what you mean? Or are you talking about frizzy edges on the the edge of the shapes?

Frizzy key edges are very common for LZX patches, especially using hard keys and viewing the black/white output key directly – this is why we overhauled our power standards for gen3. But it’s usually something that is masked within the space of the patch, and becomes an artifact of the medium, in practice. Keying performance is also going to be related to what keyer you are using and its noise floor as well. The Visual Cortex keyer is noisier than I would like, for example. I did not see anything in the thread “Diver flickering” that was uncharacteristic for the system in terms of hard key performance in general. I did see some Phase CV ADC jitter, which is a bit different (and what I mean in #5.)

I can definitely take some quantitative noise floor measurements on the outputs and compare them to Cortex ramps, so we can see where that stands on a chart. I’m interested to know if the noisiest bits are from the ADC path or from the hardware DACs/buffers themselves. If it relates to the former, I can do more interpolating (this relates to issue #2).

#11 — Z0NK0UT · 2021-08-27

nerdware wrote:

I don’t own a computer that can run the firmware updater.

What kind of computer do you own?

#12 — nerdware · 2021-08-27

Yes, the fizzy edges. You can see this clearly in the first video I posted. The second video shows the keying results. This is in a system using Malekko power supplies. I don’t get fizzy edges when keying anything other than Diver on this PSU.

I mainly use Doorway for keying BTW. I didn’t get better results using the keyer on VC. I’ve tested Diver->Doorway->VC and Diver->VC. Same results: fizzy edges. The keying video I posted used Doorway, but the VC keyer test looked the same to me. Should I just accept that hard keying Diver won’t work? You can see why soft keying in the first test video wouldn’t be much help. The waveform isn’t stable! Where does that horizontal jumping come from? Its small but its clearly there. I called the problems “jitter and flickering” in the video description.

You’ve linked issue #5 to the videos I posted Feb 2020. I described keying this noisy output as impossible because I often want clean, stable keys in my patches. So perhaps I should really say it is, for me, barely usable. I can get good results from some of the banks, but only a few.

That’s why I’m hopeful that a firmware update will fix this. I’m also unhappy that it’ll require me to purchase a device to run the updater. Obviously that’s beyond your control. I’m simply in the unfortunate position of not owning a machine that runs Windows 10, which the updater requires. This is a personal issue, rather than a technical issue with the module itself. I still want to see a firmware solution. However, if it requires a hardware solution, then the updater’s platform issue will be totally irrelevant.

I hope this post is easier to understand than my last. It’s getting late here in the UK, so this should be my last post this evening. I’ll be happy to continue the dialogue another day, of course.

Thanks.

#13 — creatorlars · 2021-08-27

nerdware wrote:

I’m also unhappy that it’ll require me to purchase a device to run the updater.

Diver has a standard USB DFU protocol built in – you won’t need to purchase any type of device to run the update. You just remove the module from your system, attach a USB-A to USB Mini-B cable to the back of your Diver module, and then plug it into your computer. Being powered from USB enables the firmware update boot mode.

Generic USB-DFU driver is all that’s required. We have our own desktop app in progress for USB-DFU updates, but in the mean time you can use a generic app that is available for free. I’ll make sure to document MacOS and Windows instructions for the firmware update, when we release one.

#14 — creatorlars · 2021-08-27

Should I just accept that hard keying Diver won’t work?

Maybe, but let’s discuss it a bit more. I will take some measurements.

Another factor is waveshape – if you are trying to key at the very top edge of a sinusoidal ramp output for example, your noise floor increases (literally exponentially). This is why modules like shapechanger, etc use a different technique for making circles (cropping the entire ramp itself).

The right answer for the look you want may be a special ramp mode, with hard keyed outputs (rather than ramps) being sent to the outputs. I’ll let that stew.

nerdware wrote:

You can see why soft keying in the first test video wouldn’t be much help. The waveform isn’t stable! Where does that horizontal jumping come from? Its small but its clearly there.

Yes, I see it! That’s what I meant by “horizontal phase CV ADC”. That’s something I know I can clean up – the worst case is we sacrifice the modulation speed a little bit on the phase CV input.

Part of the problem is that I am seeing two separate (from the electronics perspective) issues. One is that “output noise floor is higher than expected, resulting in noiser than typical keying response”. The other is “the CV input sampling has some intermittent jitter, resulting in the whole image jumping left/right by 1 pixel at random timing, if the image is frozen in place.”

Both are valid concerns and valid issues, and I will treat them both as such – and try to find solutions for both.

#15 — nerdware · 2021-08-28

This is excellent news. My earlier comments were mislead by reading a page linked to in the “Firmware Update Instructions” section of the All About Diver thread. The page linked to talked about an update utility that only runs on Windows 10. I’m very happy to learn that this is not the case.

Thanks.

#16 — Apfelmann · 2021-08-28

syncing diver via vidiot in my setup i often have to powercycle my case after the inital startup, to not get this (kinda funky) unstable output

sometimes diver then gets stuck, no lights, no power no output. i guess this is issue #1 related

1 or#2 or #5? mirrored shapes are off center with both faders all the way down, thats what bugs me the most next to #6

more ramps would be pretty neat, vco mode sound amazing

thank you

#17 — nerdware · 2021-08-28

I’m running Ubuntu on all my computers. Please see my reply to Lars on the firmware updater. Anyone like me using a system downstream from Debian can install a package called dfu-util and use that to update their Diver. I may already have the USB cables needed for the link.

Thanks.

#18 — nerdware · 2021-08-28

creatorlars wrote:

Both are valid concerns and valid issues, and I will treat them both as such – and try to find solutions for both.

As always, your support is greatly appreciated. Thanks.

#19 — Agawell · 2021-08-28

Hi nerdaware

maybe instead of purchasing a specfic device to update a single module you could try reaching out to the community here (and modulargrid) - you never know when someone a few miles away has what you need and is willing to give you a hand - maybe meet you somewhere with a laptop for example - or a friend, colleague or family member might be willing to help

I may be in the same boat with some firmware updates - I only have Macs! but I know people who have windows boxes too and vaguely a few with linux

never hurts to ask!

EDIT - just read a bit further - you appear to be sorted with your linux computers - which is of course excellent news!

#20 — sprthhfk · 2021-08-28

I’ve wished on multiple occasions that the scroll speed could move at a higher range. Is that a possibility?

#21 — nerdware · 2021-08-28

sprthhfk wrote:

I’ve wished on multiple occasions that the scroll speed could move at a higher range. Is that a possibility?

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!Thanks.

#22 — saiteron · 2021-08-28

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!

#23 — bluecondition · 2021-08-28

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.

#24 — rempesm · 2021-08-28

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?

#25 — creatorlars · 2021-08-28

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?

#26 — creatorlars · 2021-08-28

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.

#27 — sprthhfk · 2021-08-28

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.

#28 — creatorlars · 2021-08-28

nerdware wrote:

I’m running Ubuntu on all my computers. Please see my reply to Lars on the firmware updater. Anyone like me using a system downstream from Debian can install a package called dfu-util and use that to update their Diver. I may already have the USB cables needed for the link.

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.

#29 — Marizu · 2021-08-28

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.

Cheers!

#30 — creatorlars · 2021-08-28

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.

#31 — Marizu · 2021-08-28

Those outputs are coming straight out of the Diver H+V outputs and into the keyer of the Cortex.

Even when the shapes are around their largest on screen, they still have squared sides.

#32 — creatorlars · 2021-08-28

Marizu wrote:

Even when the shapes are around their largest on screen, they still have squared sides.

I am going to bet this has to do with issue #2, I’m beginning to see the pattern ultimately leading back to a consistent phase offset.

A very helpful question right now: Do any of you not see the issue present in issue #2 on your Diver? If so please describe your sync setup.

#33 — rempesm · 2021-08-28

creatorlars wrote:

Non-standard syncs.

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.

#34 — creatorlars · 2021-08-29

rempesm wrote:

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 RGB outputs from there?

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.

#35 — rempesm · 2021-08-29

creatorlars wrote:

Feed that image into the HD system via an upscaler.

creatorlars wrote:

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.

TBC2 has a built-in upscaler as well, right?

#36 — creatorlars · 2021-08-29

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.

#37 — giantmecha · 2021-08-29

A couple of Diver firmware requests:

1. 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.
2. Would it be possible to map the trig input to switch between banks (and/or anything else, really)?
3. And yeah, I’m definitely here for faster + slower scroll speeds too

#38 — creatorlars · 2021-08-29

giantmecha wrote:

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.

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.

1. 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.

1. 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?

#39 — giantmecha · 2021-08-29

1. Oh, awesome news about the triggers.

2. 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.

3. Slow: maybe about a couple of minutes for a full scroll? Fast: can it get really fast, like into audio-rate speeds?

#40 — creatorlars · 2021-08-29

giantmecha wrote:

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.

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.”

#41 — giantmecha · 2021-08-29

Oh, yeah a “shape scrambler” and/or curve function would be sweet. I find that my V Phase VC input is often free, could be good for that use case.

#42 — wiatrob · 2021-08-30

Thanks for taking a look at this @creatorlars Of late Diver is probably my most used module, either as a shape generator or an FM/other modulation Source. I never use my Diver as a visualizer (After all this time it now dawns on me the module is called a ‘waveform visualizer’ not a ‘ramp generator’ which may have been where some of my initial expectations of performance originated, oops!)

I dug through my old emails and posts about bug reports and feature requests, there may be some duplicates but a list follows. I think some of this may be in the other thread too.

Sync Issues: once the module is sync’d it’s generally solid.

I have been using it in blissful ignorance of the jitter/edge noise @nerdware has pointed out, I took a close look and they are certainly there. AFA the noisy edge I just chalked this up to system noise and patched around it. I usually have the ramps moving so this must minimize the noticeability of the jitter to me.

Also it seems to affect the H ramp more than the V ramp (I can see it happening at the single pixel offset). Which would also explain why I didn’t notice it so much in one of my main use cases (Oscillator FM)…

Issues:

1. The Seam/Single pixel offset

2. Visible Stepping even with analog CV at slow motion values. This may just be NTSC resolution unfortunately.

3. I have multiple divers and default scroll setting is different between them – I have to nudge the slider to get them to line up (neither all the way up or down results in a centered shape which I’d expect)

4. My late model diver has a different ramp shape for H-V in bank 1. The H and V each!

seem correct.

DiverHMinusV|690x240

EDIT: 5) Fix the squared - off ramp shapes, I think this might only be in the H+V/H-V but Bank 3 definitely seems wonky

Feature Requests:

1. State Save on power cycle!
2. Ramp shape crossfading/blending on a per axis basis
3. More complex ramp/gradient shapes as mentioned.
4. Slower scroll motion as mentioned.
5. Oscillator/Wavetable oscillator functionality.
6. Ability to internally scale ramps so the don’t take up the whole screen
7. Along with 6) ability to have a different ramp appear when the previous scaled ramp scrolls off-screen, or cycle through ramp shapes.
8. EAB Videolab Series II Module B pattern Source

#43 — gzifcak · 2021-09-05

My biggest request is HD if it’s possible.

#44 — Limpasen · 2021-09-06

Mine works fine! If you and some new features I would so happy. Keep up the great work! And thanks for doing all this great stuff.

#45 — esnho · 2021-09-08

Maybe the trigger input can skip to the next bank, and sliders can be used to adjust a range of “auto skip” banks?

#46 — esnho · 2021-09-08

Didn’t check if it’s already possible but, could be possible to modulate the scrolling velocity at audio or video rate?

I guess it would create a pattern of scrolling ramps with a nice effect.

#47 — rempesm · 2021-09-08

Modulate your H and V Phase CV inputs! You won’t get full video rate response on those inputs, like you won’t get what you might expect by plugging in an image or H sync oscillator, but it goes pretty darn quick.

#48 — brendanleespengler · 2021-09-23

creatorlars wrote:

Sync robustness. I have had several reports of an intermittent “blip” that occurs in the waveform at longer, but random intervals (1-2 minutes apart). I can see and confirm this issue here as well. I have a few solutions to try.

Hey Lars, not sure if ‘minutes’ was a typo, or if that’s an issue as well. But I have, and heard reports, of a sync skip that happens approx every 3-4 seconds rather than minutes. It’s been consistent with different Divers and different sync configs. MemPal is my sync source, currently, but have had same issue with different sync sources.

Looking forward to the TBC2 & Chromagnon as well as Diver update! Thx!

#49 — phosphenes · 2021-10-19

creatorlars wrote:

A VCO mode

Very excited at the prospect of this!

#50 — Apfelmann · 2021-12-16

any news here? I´d really like to get my diver fixed, no moneyz for the shiny new stuff and chromagnon might still take a while

#51 — nerdware · 2021-12-16

Yes, some of us have personal priorities which conflict with the production schedule. We may appreciate the LZX priorities while still being unhappy.

For example, I need to sell modules to pay for gen3 modules, so I’m keen to discover if Diver is a “keeper” or not. The firmware update will help, otherwise I might have to sell it as it is. A potential buyer might be unhappy about that, making this module harder to sell, and making it harder for me to buy a gen3 module.

This is just a statement of interest, of course, not a complaint.

#52 — emooh · 2021-12-16

LZX has opened preorders for new standalone instruments and has produced a new generation of analog modules in the years following the initial release of the Orion series. Updating firmware in any regular manner or in reaction to bugs or user requests hasn’t happened. As a customer, it seems releasing fully functional digital modules and expanding on their functionality through regular firmware updates is not a part of their model at this time. I hope how they have handled past projects is not an indication of how they will handle projects to come, especially as they increase in number and complexity.

#53 — Z0NK0UT · 2021-12-16

It must be said that Memory Palace firmware has been upgraded a few times since that module was released. Supporting products via firmware upgrade is part of the LZX model. Lars has been working on a project for the past year and a half. It’s an LZX software environment meant to support TBC2, Memory Palace, Diver, and Chromagnon. Admittedly, the project grew bigger and more challenging than anticipated, necessitating the release of the Gen3 modules.

It is important to keep in mind a couple things when you consider Diver’s firmware. The first is that we have one person (with occasional help from others) writing firmware for several complex instruments that have never existed. That person is also developing hardware instruments and running a manufacturing facility and a small retail/wholesale venture.

The second is that, for the last couple years, that person has had to do all of the above during a global pandemic which has disrupted the foundations of manufacturing. That disruption began in December/January of 2020, as Chinese factories began shutting down in response to COVID, and it has mutated into new challenges for LZX throughout the pandemic (which isn’t over). It is essential that we don’t underestimate the effect of the pandemic on LZX. It’s been a rough couple of years.

Diver firmware is important and it will receive an update. The module is not broken–simply flawed. Luckily that flaw will be eradicated. However, firmware-heavy instruments like TBC2 and Chromagnon are priorities over Diver firmware. Once those two products start shipping, there will be spacetime for the Diver firmware update.

Thank you all for your patience and your feedback–both propel us forward.

#54 — wednesdayayay · 2021-12-16

at least there is still talk of getting diver updated

escher sketch is what it is.

I hope there is a new gesture/interface module at some point…

trying to stay positive about this one but it was a bit of a gut punch

#55 — Apfelmann · 2021-12-16

Gutpunch indeed…hoped for an soonish Update since the day i installed diver in my Rack two years ago

#56 — phosphenes · 2021-12-22

I know this is frustrating for lots of people but its really important to remember that lots of this delay has been completely out of LZX’s hands. COVID has caused unprecedented component shortages globally and dented supply chains massively, this was also compounded by delays from the Evergiven getting stuck and blocking shipping lanes.

Huge companies buy the most components so effectively get the first pick of available stock and also have the resource to design around component shortages, when parts start to dry up it hits the smallest manufacturers of electronic goods first and hardest. In the past two years I’ve worked at two electronics companies, both which were small but still significantly larger than LZX and both really struggled getting components. These delays then require redesigns, which then requires more time for testing, which takes engineers away from Firmware and other updates. Designing Video stuff is HARD, even without all these other issues!

Getting this level of support, insight and honesty from a manufacturer is extremely unusual and shouldn’t be taken for granted. Hope the team manage to get some well earned time off soon!

If anyone’s still not convinced, I’m looking to buy a Diver in the New Year once I’ve paid for Christmas, so drop me a message then.

#57 — creatorlars · 2021-12-23

Nothing’s changed about this project being next on deck after TBC2. I hope to do some updates for Escher Sketch too, we are just trying not to set any new expectations at all until our current projects are finally wrapped.

There’s a giant world of LZX software and firmware that’s been developed over the past couple years in pursuit of TBC2, including node patching frameworks and modulation scripting. I’m excited to finally pull all of threads together, but there’s only me right now on the software side, and I’ve been struggling to wrap everything up so we can move on to this and other overdue projects. I was hoping to hire a software developer or another engineer in early 2020, but the pandemic made that impossible.

If I were to go back and know it would all be dragging out this way, I would have tackled the Diver update much earlier. I just need to carve out 2 weeks after I know the TBC2 and Chromagnon releases are going to be solid, and then we can release some of these new features for Diver.

#58 — Rik_bS · 2021-12-23

creatorlars wrote:

How slow do you want to go? At the lowest speed, how long would it take to scroll around one time?

Looks at the NLC Sloth DK for inspiration

Some of us may see 24 hours per cycle being reasonable

#59 — creatorlars · 2021-12-24

Lets’ think about the time increment in terms of resolution – if we are moving the ramp in NTSC mode, that is 720 pixels. If we divide the frame rate by 720, we get 29.97 / 720 = 0.041Hz or a period of about 25 seconds. So cycle times longer than 25 seconds would be easy to implement, but you don’t get an infinitely smooth response beyond that point like you would with an analog LFO.

So a range that maxes out at 25 secs/cycle and then a range that goes up to more like 10 minutes per cycle would be good. We can go longer – digital systems are good at keeping time.

#60 — Dr_Rek · 2022-03-18

I’ve always felt like LZX needs a full time firmware coder to work with Lars, hopefully that’s in the roadmap.

#61 — Apfelmann · 2022-07-26

Is this still Happening? Its a bit frustrating seeing all this new stuff happening while this olde thingy really needs an Update

#62 — meudiademorte · 2022-07-26

Lars wrote in this thread that a diver firmware is coming, after tbc2 and chromagnon is ready.

#63 — creatorlars · 2022-07-27

I’ve been consumed by the Gen3 firmware architecture (TBC2/Chromagnon/ESG3/DSG3) still. These are rather urgent projects – TBC2 was supposed to ship before Diver in the first place, and without an output encoder we are unable to supply you all with video synthesizers, so while I regret the timelines, those are the priorities. I was hoping to hire another software developer in 2020, but then the pandemic happened.

The plan is still to resolve bug fixes with Diver, Escher Sketch, and whatever else needs it, after the above releases go out the door. I would love to take a break from the current projects and do this for a couple weeks instead, but right now it’s impossible.

#64 — wiatrob · 2022-07-28

I want to see these issues fixed as much as anyone (having three dang divers) but I offer this: In the interim, embrace the flaws! What used to drive me absolutely crazee I now hardly even notice. In fact, I like to point it out to folk in patches - 'look, there’s the single pixel offset!"

#65 — nerdware · 2022-07-28

Yes, I’ve been getting a lot of use from my Diver in ways that don’t expose the glitches. Sometimes I wish I had a second Diver. So I’m still waiting for a firmware update, but I’m very patient.

#66 — rempesm · 2022-07-28

Diver mixed with various things into Aux/Alpha of Memory Palace in Mesh mode is kind of a dream made real. The current warts are less visible when you’re using it as a modulator.

#67 — nerdware · 2022-07-28

Yes, this year I’ve only used Diver as a modulator. It’s wonderful. The scrolling modes add another level of modulation, of course, increasing the value of this module as a modulator. Modulating the speed of scrolling is another matter.

So all this fun helps obscure the firmware issues.

#68 — brendanleespengler · 2022-07-28

I have to interject here. Diver is useless in its current form, especially in professional use cases. You simply cannot create a stable ramp, and providing animations for a client w that sync blip every couple seconds is embarrassing. Using it for modulation only makes matters worse, affecting other parts of your composition. I’ve bought 3 different Divers and they all have been garbage, for years now. Even people who know nothing about video synthesis ask me why images made with the Diver are flickering. This is not okay.

#69 — nerdware · 2022-07-28

I agree that if your Diver behaves as you describe, that would be a serious problem. I only have a single Diver, so I have only one data point. All I can say is mine doesn’t do that, but it has two different issues. Both issues become problems when Diver is used for keying. I don’t see how you can mitigate the problem with yours.

So, while I’m getting around my problems with Diver, I’m not saying everyone else can do the same. While I can afford to be patient, I appreciate why you cannot.

#70 — creatorlars · 2022-07-28

It sounds like there’s an issue in your sync chain somewhere; there shouldn’t be a sync blip like that. Now, Diver appears in some cases to be quite sensitive to sync chain issues in general, so that doesn’t mean you’ve connected something the wrong way or that there’s not a different issue. I’m hoping (and think I can) improve sync robustness of the module in general in a software update, however that’s not a guarantee if the issue is related to the sync source itself.

A lot of our sync distribution woes between Mempal, Diver, Vidiot, etc led to our thinking with the current approach to Gen3 modules, where each module has an identical rear sync IO board and genlock circuit.

All that is to say, you may be able to solve your Diver(s) issue with a different approach to sync distribution. And we may also be able to improve it with a software update, such that lock robustness issues are smoothed over.

#71 — wiatrob · 2022-08-08

The assumption for my post was that Diver does sync (also excepting @nerdware’s keying issue). Speaking from three data points and from helping folks sync Divers. I’m not discounting your experience - Diver IS tricky to sync, no matter what your sync chain or revision of Diver. Usually, the solution is to change the entire sync chain arrangement, or even change your sync source. I have the luxury of doing that, having been at this long enough to have multiple generations of sync generators (generating sync signals - made a tongue twister there).

#72 — saiteron · 2022-08-09

i’ve had 3 Divers (had 2, sold both due to financial difficulties, bought another) and in all cases i was able to resolve any issues by reorganizing sync chain. putting Diver close to front of chain seems best. successful sync with Cadet I, Visual Cortex and Mem Pal were all possible with Diver 1-2 modules distance from sync source. in my current setup i use a Syntonie VU001 for composite sync distribution from Visual Cortex and it works great - Visible Signals Dual Distrib also works in this role.

#73 — BombayBump · 2022-08-11

I have to disagree. Granted my use case is 99% related to visualizing music so diver is a natural pairing but I’ve been able to get some fantastic results especially when keying out certain aspects which often times removes the issue with the blip all together.

#74 — Jefro · 2022-08-11

Likewise. When I have issues, it’s usually the sync order.

#75 — dryodryo · 2022-08-15

A Diver came up for sale on Reverb a couple days ago and I didn’t buy it because SD. Until it’s certain that the hardware can support 1080i, I won’t be pulling the trigger on Diver. A hybrid SD/HD environment isn’t going to work for me. I’ve built the whole rig to run on one house sync as God intended.

#76 — Dr_Rek · 2022-08-15

I’m entering two video mixer world so I can keep them all in the show together. V4EX for the SD, and V40HD for the component / hdmi HD (ESG3, Chromagnon, Positronic Recursion Studio, Hypno) and mixing the V4EX output into the final HD mix.

#77 — leolodreamland · 2022-08-19

how are those new ramps looking?

#78 — phosphenes · 2022-09-15

Is Diver likely to be re-stocked in 2022?

#79 — Z0NK0UT · 2022-09-15

Diver is out of production and will not be restocked.

#80 — phosphenes · 2022-09-15

Damn that’s a shame! Hopefully we’ll see a gen 3 version eventually? I’ll keep an eye out for a used one

#81 — Dr_Rek · 2022-09-15

Have you all considered open sourcing the firmware, so the firmware fluent heads in community could try custom upgrades? It seems like it’s going to be awhile until @creatorlars or the future firmware employee can deal with it.

#82 — creatorlars · 2022-09-15

Are you volunteering?

#83 — Dr_Rek · 2022-09-15

lol, wish I could, not really a coder. But I’m hoping those coder folks are out there in the community

#84 — creatorlars · 2022-09-15

I have zero problems with open sourcing this and other projects, it’s just about the time it takes to write build instructions for the project, clean up the repositories, and document the tools required. In that time, I can probably be half way to a firmware revision. We’ll be back to Diver soon now, the firmware update will come in the wake of the TBC2 release.

#85 — wednesdayayay · 2022-09-15

I am so excited that we are on the cusp of TBC2 getting into systems.

We just got the shipping notification for our first DSG we are so pumped!

#86 — csboling · 2022-09-16

If you were to just push one or more repositories, whatever their current state, as an on-again-off-again professional FPGA and embedded developer I am 100% willing to wing it, and write documentation. I’m pretty sure I’m not the only LZX user with the skillset and inclination to hack some Orion firmware / gateware. Exciting possibilities for alt firmware as well.

#87 — creatorlars · 2022-09-16

That is all good to know!

#88 — dryodryo · 2022-09-17

Z0NK0UT wrote:

Diver is out of production and will not be restocked.

Ouch. I thought there was going to be a Diver mk2, similar to Memory Palace mk2, with support for HD timings. But when Diver disappeared from the LZX home page, I suspected something was up.

Looks like a fantastic module, and hope there will be a Gen3 equivalent.

#89 — Dr_Rek · 2022-09-19

Yes, this is what I’m talking about

Excuses about how much @creatorlars has on his plate are not helping us as a community trying to enjoy this companies modules. Open source the firmwares for user modifications!

#90 — phosphenes · 2022-09-20

If anyone decides they want to sell a Diver drop me a message, UK based

#91 — BittahWizard · 2022-10-03

Does this mean that there will not be a firmware update for Diver? Was looking forward to the HD ramps and several of the other features that were discussed.

#92 — Z0NK0UT · 2022-10-04

There will be a firmware update, but HD sync may not be possible.

#93 — nerdware · 2022-10-04

This is one of the reasons why I have no use for HD video hardware. I’m only interested in downscaling HD to SD. It may be years before I can consider using HD, if I ever do. I’m still interested in the firmware update, of course. I simply never expected or wanted HD support for Diver, so this news doesn’t affect me at all.

Thanks.

#94 — dryodryo · 2022-10-07

nerdware wrote:

This is one of the reasons why I have no use for HD video hardware

This is just one module that doesn’t support HD. And it’s because it’s digital. Basically all of the analog modules work fine at HD timings. The worst that can happen is that things go a little soft in the horizontal dimension.

#95 — nerdware · 2022-10-08

True, the main reason I have no use for HD is because I’d need an ESD that generates signals I can capture, and such a module is not yet available. However, Diver is the one module I have now that uses a composite sync signal. So I have a good reason to keep my VC, which cannot do HD.

I’m at the point now where I must decide which modules to sell to pay for Gen3 modules.

HD support in Diver could’ve been an argument for HD. Without that support, that’s one less argument on the plus side. Budget constraints are a huge argument on the minus side.

So it makes sense for me to use SD only for the forseeable future.

The firmware update is still a priority for me.

#96 — jwsmithwick1 · 2022-10-08

HD is nice, however I am capable of doing a lot more in SD at the moment (with Diver and especially with Memory Palace). I scale the SD signals up to HD with a Decimator. I’m happy with the results.

Diver definitely needs an update. The x axis is offset when fully up or down. It is crucial to put the diver right after the Visual Cortex in the sync chain. All the other problems I had noticed with the module disappeared once I set up the sync chain like that.

#97 — monads · 2022-10-08

I’m gonna be honest and some of you are like ‘pro’ with HD. For me I’m not shooting anything in HD/4K so just manipulating SD and/or upscaling is good enough. I’m just looking forward to TBC2 release at the moment and integration with SD stuff??? I’d like all focus on TBC2 release so everything after follows suit.

#98 — Mojodavey · 2022-10-08

Excited to see what can happen with the firmware updates!

currently my diver does sync with HD, however it only syncs the V ramps, the H ramps are a horrible scrolling mess, so it sorta works fine, but its just very limited now that its only 1 set of ramps

#100 — Vdot · 2022-10-10

Have Shapechanger and Navigator been confirmed to work in HD?!

#101 — rempesm · 2022-10-10

Shapechanger has no sync connection so format timing is irrelevant, it will just work.

Navigator’s sync connection is just to avoid frame tearing during rotation. You could run it without a sync connection and the X/Y position controls will work just fine at any timing.

It’s possible that Navigator can detect the sync pulses out from other timings than NTSC/PAL to work correctly during auto-rotation but that just needs to be methodically tested rather than guessed at.

#102 — dryodryo · 2022-10-10

nerdware wrote:

True, the main reason I have no use for HD is because I’d need an ESD that generates signals I can capture, and such a module is not yet available.

What’s an ESD? Sorry, I’m not familiar with that TLI.

#103 — nerdware · 2022-10-11

Sorry, that should’ve been ESG. Typo.

#104 — dryodryo · 2022-10-11

So you’re saying you can only capture some format that ESG3 can’t generate?

#105 — nerdware · 2022-10-11

No, there’s a different problem - discussed in another thread.

#106 — creatorlars · 2022-10-21

As requested, I have archived the project and source files in their existing states for Diver & Escher Sketch in the public facing repository here:

GitHub

https://github.com/lzxindustries/lzxsoftwareLZX Industries Open Source Software Projects. Contribute to lzxindustries/lzxsoftware development by creating an account on GitHub.

Link: GitHub - lzxindustries/lzxsoftware: LZX Industries Open Source Software Projects

The next step for this repository would be to convert the projects to remove dependencies on VisualGDB and document a more open build toolchain. Additionally, instructions for debugger access to the hardware should be documented.

#107 — rempesm · 2022-10-21

@csboling Time to get hacking!

#108 — Dr_Rek · 2022-10-26

Thank you Lars!

It’s officially a race now, who can get the next firmware update out first, Lars or the community?

With X amount of other firmwares priority in Lar’s queue before this one, my bet could be on community

Looking forward to future updates for Diver

#109 — Rik_bS · 2022-10-26

Is this where we soon see someone playing Doom on a Diver?

#110 — saiteron · 2022-11-01

Doom on Escher would actually be pretty amazing. stylus to aim, buttons to move, reload, shoot

#111 — Dewb · 2022-11-02

Thank you Lars! This is awesome. I’m pretty happy with Diver as-is, but having a programmable experimentation platform that already outputs synchronized 1V video is transformative for the more software-minded DIYers out there.

Armed with some prior STM32 experience, I was able to set up the VisualGDB toolchain (with the 30-day trial), build the firmware, and flash it to the hardware successfully.

During this process I took some notes and screenshots. If it would be helpful, I’d be more than happy to edit those into a draft build guide and make a PR.

I’ve used VS Code + PlatformIO for some AVR and ESP32 projects, I believe their STM32 support is also good. If that is the kind of open build toolchain you had in mind, I don’t think it would be hard to get that conversion rolling.

#112 — CountFunkula · 2022-11-02

Way to go Dewb! I’m in the same boat. I have two divers and use at least one in most patches. Diver is a really exciting platform and it’s capable of some serious fun above and beyond its current time-domain mutation task. Even relatively simple spins like assigning one of the scroll inputs to something like buffer stride are going to be a blast! I can’t wait to get a “devDiver” up and running! @Dewb I’d love to see your notes.

#113 — creatorlars · 2022-11-02

Nice work! The code is messy, but not too big – at least can get you started with a synchronous output buffer. A line buffer based rasterizer may be possible to implement, for real time graphics. I’ll try to provide more of a development kit style release after porting in more recent software library classes.

#114 — Dewb · 2022-11-04

That sounds awesome!

When you get a chance could you share the pinout of the 6-pin connector? I assume there are JTAG and/or SWD pins on there (or somewhere else on the board?)

#115 — eyesnoface · 2022-11-07

J8 Pin1(GND) as it corresponds to the actual board connections is the bottom most pad and is square

#116 — Dewb · 2022-11-07

Awesome, thanks so much! <3

#117 — creatorlars · 2022-11-07

If you’ve got it building/uploading and just want to mess with the waveform generation, that’s all done on line 1029 of main.cpp:

void GenerateLUT(uint8_t waveform)
{
    for (uint32_t i = 0; i < vres; i++)
    {
        float a = float(i) / float(vres);
        float b = (a*a) * 1023.0;
        float c = (a * 1023.0 * 2.0) - (b);

        switch (waveform)
        {
            case 0: lut[i] = ((i*DAC_MAX_VALUE) / vres) & 1023; break;
            case 1: lut[i] = uint16_t(c) & 1023; break;
            case 2: lut[i] = uint16_t(b) & 1023; break;
            case 3: lut[i] = ((i*DAC_MAX_VALUE) / vres) & 0b1111000000; break;
            case 4: lut[i] = ((i*DAC_MAX_VALUE) / vres) & 0b1110000000; break;
            case 5: lut[i] = ((i*DAC_MAX_VALUE) / vres) & 0b1100000000; break;

        }
    }
}

#118 — Dewb · 2022-11-13

@CountFunkula Here are my draft notes on building with VisualGDB and building with PlatformIO, which is still a work in progress (the firmware builds and loads, but the GPIO controls don’t work yet.) which now works!

Later this afternoon (maybe 4:30 ET?) I’ll be on Discord working on getting a debugger running, and investigating what’s going on with the PlatformIO build, if anyone wants to follow along.

#119 — Dewb · 2022-11-21

Debugging with a ST-Link V2 clone or an official V2-ISOL works!

A couple other folks have now successfully built, modified, and loaded Diver firmware with the PlatformIO branch, and I’ve fixed a few issues and updated the documentation a bit: BUILDING-PlatformIO.md

#120 — meudiademorte · 2022-11-21

this is really dope but have no idea how to use it. have to dive into the documantion. did you already did some new modes or is this still a “open to play” programming thing (which is way over my capabilities)

#121 — creatorlars · 2022-11-23

Awesome! Y’all are getting me excited to open source TBC2 and other projects.

#122 — Robbertunist · 2022-11-27

Thanks again @Dewb for your help setting this up & to @VanTa for the really cool Perlin Noise patches, cases 8 to 17 in the code, banks 9 to 18. I haven’t tried the latest bank 19 that Vanta programmed up on Thursday evening (Euro time) during a Discord chat.

The USB port on the back of Diver works perfectly fine for flashing the firmware rather than using a Jtag device & connecting up the 6 pins to it.

This evening, I was jamming with a mate & thought, “Let’s hear how the Perlin Noise sounds!”

The new banks sound really sick! Really really surprising & especially when using the 2x CV inputs & the signal in on Diver.

Thanks again @creatorlars for making Diver’s code accessible to us here in the community

#123 — creatorlars · 2022-11-28

Robbertunist wrote:

Thanks again > @creatorlars> for making Diver’s code accessible to us here in the community

No problem – but I just posted it up, @Dewb did all the accessibility work!

#124 — a_digital_index · 2022-11-29

Sorry to be asking something so obvious but where can I follow what changes @VanTa has made to the Diver code?

#125 — Dewb · 2022-11-29

If you know how to use GitHub, you can follow the PlatformIO build guide above and either clone my fork for my changes, or clone Vanta’s fork of my fork for his changes plus some of my changes.

If you don’t want to do that, hang tight, we’re working on a strategy for allowing people to get all the community extensions in one go.

#126 — a_digital_index · 2022-11-29

Thanks @Dewb. I’m probably best to hang tight or have a friend walk me through it as this is outside my wheelhouse. But is there somewhere where I could follow the conversation about updates? Or was it a Discord stream?

#127 — phosphenes · 2022-11-29

The Diver GAS is real! Open source hardware next please haha?

#128 — creatorlars · 2022-11-29

I’m all about doing an open video dev platform / module – but would want the project to start that way. If we released Diver as it is, it would be “one big step behind” existing Gen3 environment. The most natural way to do this would be to replace the composite video decoder (TVP5150AM1) with the Lattice iCE40 FPGA genlockable SD/HD sync generator infrastructure from the DSG3/ESG3 modules (and the Syntonie SD/HD encoder as well.) The DAC could be exchanged with something like ADV7123 to provide HD capable output speeds. We could keep MCU selection the same, and strategy for interfacing the same, and the best part is all the costs would be equivalent. We may want to add things like full MIDI interface and USB IO. This type of platform would be like a micro version of TBC2/MemPal – not capable of full video stream processing and frame buffers, but perfectly capable of video synchronous waveform, ramp and primitive graphics generation. Let’s keep this conversation going throughout 2023.

#129 — VanTa · 2022-11-29

That sounds fantastic!! When I started diving into diver’s code, MIDI came first to my mind. It would make it super powerful.

A new device or platform for pattern generation with HD timings would be amazing. Do you think the current MCU would be enough?

A triple DAC is also the right way to go I think, more in the gen3 vein.

I’d be happy to collaborate in any way I can, mostly code.

#130 — creatorlars · 2022-11-29

MCU selection doesn’t need to be locked down for an updated version. I am sure supply chain would be a factor. One of the reasons I chose STM32F4 series is that it clocks up to 216MHz, and that’s a natural 8X PLL multiple up from the 27MHz SD pixel clock. Introducing 74.176MHz / 74.25MHz HD clock options would be possible, but you only get a clock speed of 2X pixel clock with the STM32F4. So that would give you a rough idea of SD (8 clocks/pixel) vs HD (2 clocks/pixel) with the existing MCU. For 8 clocks/pixel at HD we’d want a clock PLL capable of up to 594MHz ideally. That’s more in league with the TBC2/Mk2 SoC (dual Arm9 clocked at 667MHz). But maybe there are some approachable MCU type parts that can do it – I haven’t looked for a few years.

#131 — CountFunkula · 2022-11-30

@Dewb Beautiful refactor! I really like the new bank organization and selection mechanism! I haven’t had time to run any of the latest commits from @VanTa 's fork, but they’re looking great!

Do we have a community punch list for this project?

Some of the most mentioned issues from this thread are:

1. State Save on power cycle

2. “THE SEAM”

3. More ramp/gradient shapes

4. Scroll Speed Range Control
5. Oscillator/Wavetable oscillator functionality.

The new approach to bank settings makes it a snap to address #3 and #5. I’ve been playing with scroll params and I just saw a commit from @VanTa with a touch-up somewhere re: scroll speed.

#132 — VanTa · 2022-11-30

Dewb did the scroll speed selection already.

The seam!!! Hahah

There’s also a square wave oscillator from him that is really fun to play with.

#133 — creatorlars · 2022-12-01

CountFunkula wrote:

State Save on power cycle

This should be possible by using a portion of the Flash to store persistence data.

Related to “the seam”, a few theories on what could be going on…

– We may need calibration for the CV input to null out a variable DC offset between units – this is related to storing some variables in the Flash, and also the addition of a calibration mode.

– The timing of the DMA compared to the ADC sampling may need to be audited. Maybe there’s an alignment mismatch in the DMA to GPIO transfer relative to the ADC sampling (which happens once per HSYNC.) In order to provide perfect alignment we may need to double buffer the incoming samples and align them to the next frame – memory’s going to be limited, so a frame buffer/TBC function isn’t quite possible. But maybe there’s a simple timing error here where we just need to shift the read point.

– It relates to the DMA interrupt timing vs real video sync timing. We may need to implement timer control over the DMA interrupt, and set timer control registers to video sync period numbers. I think right now the DMA is just driven by the HSYNC interrupt – which given the MCU clock is genlocked, should be synchronous – but possibly triggered slightly later than desired.

After my pending TBC2 release I can get the PlatformIO build running and see if I can jump in and help tackle some of these.

#134 — Dewb · 2022-12-01

creatorlars wrote:

It relates to the DMA interrupt timing vs real video sync timing.

This is where my suspicions are leaning right now – for me, the seam is unaffected by the wave input. I haven’t cut together a mode that only has the LUT DMA and none of the wave sampling to prove this, but that’s probably next on the list after the current round of stuff. I’m not going to be free to hack on this for a few more days, unfortunately.

creatorlars wrote:

After my pending TBC2 release I can get the PlatformIO build running and see if I can jump in and help tackle some of these.

That would be awesome! I (quite selfishly) haven’t wanted to tempt you away from TBC2 work, but I can make a PR of the PlatformIO stuff back to the official repo for your review when/if you are ready/interested. The dewb/platformio branch doesn’t involve any changes to the code itself, and with a few additional tweaks the PlatformIO files could probably coexist next to the VisualGDB stuff if you wanted to maintain simultaneous support for both toolchains in the same codebase. (I think the strongest argument against doing that would be that it would confuse non-VisualGDB users.) All the more aggressive changes are happening in dewb/refactor (and @VanTa’s fork of same.)

#135 — creatorlars · 2022-12-01

Dewb wrote:

That would be awesome! I (quite selfishly) haven’t wanted to tempt you away from TBC2 work, but I can make a PR of the PlatformIO stuff back to the official repo for your review when/if you are ready/interested. The > > dewb/platformio>> branch doesn’t involve any changes to the code itself, and with a few additional tweaks the PlatformIO files could probably coexist next to the VisualGDB stuff if you wanted to maintain simultaneous support for both toolchains in the same codebase. (I think the strongest argument against doing that would be that it would confuse non-VisualGDB users.) All the more aggressive changes are happening in > > dewb/refactor>> (and > @VanTa> ’s fork of same.)

Yeah I am excited to talk about it! I have at least 10K hours under my belt in embedded development since writing the Diver code, so there are lots of ideas on better ways to do the infrastructure. There’s a big library of C++ code it would be nice to integrate, to make things more portable. We should be able to write an app that compiles the same generators for different platforms (TBC2 + Midi Controller mapping vs Diver hardware for example.)

#136 — Dewb · 2022-12-01

a_digital_index wrote:

Thanks > @Dewb> . I’m probably best to hang tight or have a friend walk me through it as this is outside my wheelhouse. But is there somewhere where I could follow the conversation about updates? Or was it a Discord stream?

Yes, lots of the discussion around this is happening on Discord. We did walk through the setup and build process on a video stream a week or so ago. Wish I’d recorded that, sorry! Once things have stabilized a bit more perhaps we can get something recorded. But the text instructions cover the same material.

CountFunkula wrote:

@Dewb> Beautiful refactor! I really like the new bank organization and selection mechanism! I haven’t had time to run any of the latest commits from > @VanTa> 's fork, but they’re looking great!

Do we have a community punch list for this project?>>>> Some of the most mentioned issues from this thread are:

Thank you! And yes, that punch list matches our Discord discussions. @VanTa and I immediately wanted to tackle some of those things, and after our initial round of conversations and experiments it became clear our work was going to conflict if we didn’t do some prep to make it easier to aggregate different takes on the same ideas. Everybody wanted to add additional parameters to the generators, change the scroll behavior, introduce new button-hold combos, etc., and rather than address those things as they came up in our new-mode experiments, it seemed prudent to invest in a platform for collaboration.

I got a chance to do a marathon session last weekend and we got most of the flexibility in place. That directly addresses 3/4/5 (more shapes, scroll range control, and some primitive oscillator prototypes) and the state management is wrapped up in a class so we’re probably close to getting state persistence for both the current banks and any new banks we add.

creatorlars wrote:

Yeah I am excited to talk about it! I have at least 10K hours under my belt in embedded development since writing the Diver code, so there are lots of ideas on better ways to do the infrastructure. There’s a big library of C++ code it would be nice to integrate, to make things more portable. We should be able to write an app that compiles the same generators for different platforms (TBC2 + Midi Controller mapping vs Diver hardware for example.)

Awesome! I’m sure you have much better ideas/constructs for organizing the infrastructure, anything we’re doing in the refactor branch can be considered temporary hacks and potentially get tossed when you’re ready to share more.

#137 — creatorlars · 2022-12-01

Dewb wrote:

Awesome! I’m sure you have much better ideas/constructs for organizing the infrastructure, anything we’re doing in the refactor branch can be considered temporary hacks and potentially get tossed when you’re ready to share more.

We can compare notes, I am excited to see what y’all have written. If you have a new bank/mode manager working that could just become part of the Diver app – I am most interested in adding a virtual interface to the UI controls, and to buffer/DMA access. Then the Diver app could be added as a software node running alongside everything else in TBC2’s engine, and the output encoders would be able to select it as a source.

#138 — creatorlars · 2022-12-01

Dewb wrote:

It relates to the DMA interrupt timing vs real video sync timing.

This is where my suspicions are leaning right now – for me, the seam is unaffected by the wave input. I haven’t cut together a mode that only has the LUT DMA and none of the wave sampling to prove this, but that’s probably next on the list after the current round of stuff. I’m not going to be free to hack on this for a few more days, unfortunately.

Yeah, it may still be the DMA’s fault on the read side too (the DMA should possibly start a clock or two before the line resets, instead of after the pulse?). What I think we may be seeing is the last sample of line #2 for example, showing up as the first sample of line #3.

To get better control of all this we should be able to set up two of the hardware timers as pixel/line counters. The pixel counts should be 1716 / 1728 pixels and 525 / 625 lines depending on NTSC / PAL mode. Then we should be in sync with the input video without any “hard reset” of the DMA triggered by the external HSYNC signal, but with an offset that can be nudged until input and output HSYNC/VSYNC are synchronous. This is similar to how the FPGA sync generators work, but we don’t have to worry about a PLL / VCXO for Diver, since it’s clock comes in synchronous already.

#139 — Noeppen · 2022-12-03

I‘m selling a Diver, based in Germany.

#141 — Dr_Rek · 2022-12-20

Ooooh! Excited to load the newest DIY firmware when it’s easier to achieve. I can handle loading a firmware via USB port, but is it that easy yet?

#142 — TheEarthsMoon · 2023-01-17

Thanks for sharing these new firmware candidates. I finally got around to updating the Escher Sketch and the Diver earlier today. They both took the firmware update via usb and are working. Can’t wait to mess with them some more this evening. Thanks again ;}

#143 — Dr_Rek · 2023-01-23

Oh nice, what’s the Escher sketch firmware update add?

#144 — wednesdayayay · 2023-01-24

uh oh if Escher sketch is available I may be able to get myself setup to start participating!

#145 — sprthhfk · 2023-01-24

Any idea how far off the big firmware update might be? Still dreaming of Diver’s oscillator mode

#146 — creatorlars · 2023-01-24

Looks like we’ll be done with the TBC2 post release updates (bugfixes, and a few remaining features) some time in February. I’m still planning to update Diver when TBC2 development parks.

#147 — Dr_Rek · 2023-04-12

Got this installed last night on my Diver, after the STM32 package install, I also had to install Homebrew, and libusb (terminal command “brew install libusb”) to get process to work on my Mac, fyi for anyone else who tries this out. You’ll get a warning about libusb not found indicating you need to do this when running Upload. @dewb mentioned some folks maybe the STM32 package install will be enough on discord.

#148 — Dr_Rek · 2023-04-17

Refactor firmware stoped responding after a couple power cycles, ended up on Platformio earlier build and it’s mostly stable. Have to power cycle it sometimes if it doesn’t boot correctly.

#149 — COLLIZHN · 2023-11-14

Hi Lars, just looking for an update on the Driver firmware revision. How goes it? I don’t see any previous updated firmware listed on the site, so I am assuming this is still a work in progress since TBC2 just got finalized a little while ago?

#150 — monads · 2023-11-14

^TBC2 is not “finalized” I hope. Waiting for the below and hopefully 240p60 support. Haven’t heard anything on Diver or MP official firmware updates.

Firmware 1.1.0 - includes any new feature adds (Component proc amp, Screensaver, etc.)

#151 — Apfelmann · 2023-12-20

any chance on getting this thing fixed anytime soon? This is just a pita with a vidiot based setup and chromagnon still far away i really struggle with sync and freezing and shapes not being centered and its been a while now

#152 — Z0NK0UT · 2023-12-20

Have you tried any of the user firmware variations since Lars made it open source?

#153 — Apfelmann · 2023-12-21

Jep, both with mixed results. Still unstable, still freezes sometimes, some days it needs multiple powercycles to work at all, that annoying seam is still there, still no state save on powercycle.

#154 — Z0NK0UT · 2023-12-21

Still syncing to Vidiot? If you can run a stronger sync through Vidiot for Diver to latch onto, you might have better luck.