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
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.
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?
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.
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.
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.
@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:
State Save on power cycle
“THE SEAM”
More ramp/gradient shapes
Scroll Speed Range Control
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.
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.
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.
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.)
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.
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.
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.
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.
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 ;}
