Jump to content

latigid on

Frequent Writer
  • Posts

    2,516
  • Joined

  • Last visited

  • Days Won

    147

Posts posted by latigid on

  1. Nice to see the Dominion in action! I have a eurorack version of the Polivoks with the original Russian ICs. It's a cool design because the filter corner frequency is controlled by the variable slew rate of one op amp. Quite a different sound!

  2. Hi,

    Just now, yogi said:

    Thanks, mainly interested in an 'F4 build. I have the STM tool chain setup so can/will build here. Another 'dumb' question, aside from my system's Env Var "MIOS32_Processor", shouldn't have to make any changes to the Makefile or the source for an 'F4? Or do I have to complete this section in Make:

    
    # (following source stubs not relevant for Cortex M3 derivatives)
    THUMB_AS_SOURCE =
    ARM_SOURCE      =
    ARM_AS_SOURCE   =

    I've built the STM hex without modifying anything, as long as the correct variables are set it should compile no worries.

     

     

    Just now, yogi said:

    I have the older CS board, but your board is wired different, so a new SW build (for a 'F4) may not work with the older layout? The pre-built bin, on the DL page, for the Seq4 Lite is based on an older Seq4 version, so I guess that the newer sources on the SVN only supports your newer layout.

    I haven't looked too much into the firmware, but the button assignments for the "SRIO" version are done with "m" for the matrix. To use an old CS board with an STM32F4 Core, you might have to go through and tweak the pin assignments -- could be possible!

     

     

    Just now, yogi said:

    Got the original SEQ4Lite board ages ago (and  an LPCXpesso) but put it aside for a long time. Finally got around to it  last year and big surprise, LPC core boards are long gone. Had a go at wiring the LPC 'core board' but then got frustrated with the perfboard (single sided) I was using, so it went back into a box ( worst is, I didn't use sockets for the LPC headers; SO... would have to de-solder half the pins to start again with better perf board ).

    Sounds like a challenge :). You can ask on the Fleamarket -- maybe someone has an old LPC Core to sell?

     

    Just now, yogi said:

    Well, I guess I can either start again with new Core/CS/parts or 'man up' and finish my hand wired LPC build on the cr@p board :(  I really like your version, very clean layout. The single cable interconnection is great and for this app, don't really need a full 'F4 core board; just the J8/9, SD and midi headers.

    You could do it like this, of course you'd need a way to break out the MIDI and a method of mounting the DISCO board (no mounting holes -- custom acrylic case with the pins straight on the plastic??!! Scrap piece of perfboard? Also, the logic is only 3V, so you may run into trouble running the LEDs

     

    Just now, yogi said:

    Have to think about this, really would like to build a full Seq4 but Smash has been 'out of stock'  on the Wilba board for a long time; aren't you working on a new board set? Guessing he may be holding off  till your boards are ready. So kind of want to not spend on replacing stuff I already bought and save my budget for the 'full monty'.

    Yogi

     

    I had one builder tell me he writes on the full V4 and transfers to the V4L for live performances. So already there's a possibility of avoiding redundancy. :) The cost of the V4L is probably around $100 all up, the full is quite a bit more. I don't have any info on the Wilba version's availability, nor smashTV's plans for it. My work is still under development, but it's coming together. As long as Tim chooses to continue selling, you'll have the option of either project.

     

     

  3. You can change for 8-bit by closing solder jumpers on the PCB:

     

    As for LCDs: don't be such a cheapass! The price and availability of these has come down hugely over the years. I would even go a step further and look at installing an OLED, just make sure it can handle +5V logic. Also ensure the mechanical fit works with the mounting holes/cutout on the CS PCB. Usually these things are pretty standard, but you can never be too sure.

     

  4. To be clear, the correct path of the HWCFG is

    [...]\hwcfg\wilba\MBSEQ_HW.V4

     

    How are you uploading the HWCFG file? Does your SEQ have an external SD card slot? Did you try formatting the card/ensuring that there's only one instance of MBSEQ_HW.V4?

    Are all of the buttons (and encoders) working? If there's a hardware problem with the button-LED matrix, then you should see issues there too.

  5. If you look at the Base PCB, they were kind enough to break out the ADC pins:

    J5.thumb.PNG.448b94ec5d71ec4e544cb9138d7:

     

    You have to enable the AINs by compiling new SID firmware:

    http://www.ucapps.de/midibox_sid_manual_fp.html

    Quote

    bullet.gif Analog Control Elements

    With MIDIbox SID V2, analog control elements like pots, faders and joysticks are natively supported. Everything you can find in the forum about such an extension for V1 is obsolete, especially because a dedicated driver is used instead of MIOS_AIN for optimized performance.

    This feature has to be explicitely enabled within the setup_*.asm file by setting DEFAULT_J5_FUNCTION to 1 - once you did this, all unusued analog inputs must be clamped to ground in order to prevent random values! This is especially required for the slave modules, when the master firmware will be transfered to the slaves via ECAN (clone feature).

    All 8 analog inputs are sampled with a frequency of 125 Hz. Multiplexing (-> MBHP_AIN module) is *not* supported! So, 8 inputs are maximum.

    The firmware currently only uses the first 5 inputs of J5, the remaining 3 are reserved for future features.

    The converted values are forwarded to the knob handler. This generic approach gives you all advantages of the knob concept: value changes can be forwarded to two sound parameters, a Min/Max range can be specified, and the converted values are also available as modulation source!

    The feature behaves differently on master and slaves:

    • Master: analog inputs are forwarded to the *selected* SIDs. This has the advantage, that each SID can be controlled from a single set of pots and/or joysticks. If you find this impractical, a small and harmless firmware patch (AIN_NotifyChange: remove the branch to "AIN_NotifyChange_Master") allows you to realize a dedicated control for the master only.
    • Slave: analog inputs are only handled internally independent from the selection.

    Note that this feature can also be used to control the SID from analog signal sources, e.g. from an analog step sequencer, or an analog LFO.

     

    take special note that unused inputs must be connected to ground. So if you used the first 4, clamp the 5th. I've got no idea if anything will be different for the sammich variant, as some of the pins are evidently supplying data to the LCD.

     

    I take it you want actual CV rather than pots, so you should use clamping diodes or a rail to rail op amp limiter to protect the PIC from over/undervoltages.

     

  6. 6 hours ago, mongrol said:

    Yeah I know what they do. I'm wondering why they aren't treated the same from the UI point of view. You could remove the Trg and Prm layer buttons and have just a "layer button". Since you can't have more than 16 layers then they'll fit in the selection buttons. You could have trgs on the left 8 buttons and prm's on teh right. Or use duo LED's and have trg's one colour and prm's the other.

    I get what you mean, but I still think separate buttons are better. Also it doesn't add cost or complexity to the UI, rather your idea would mean having to guess the function instead of glancing at what button around the wheel was lit (the 16 "selection" buttons have no labels as they're multi-use). The other point to consider is that Trig and Para each have two functions, one to edit what's actually in use and the other to select values/toggle triggers on or off.

     

    20 minutes ago, lis0r said:

    Will this new layout fit into the old aluminium cases, or should I still plan on obtaining a current SEQ V4 CS PCB?

    What are the internal dimensions of the Heidenreich case? Maybe it will fit but first the PCB sets have to be designed. You'd have to order your own front panel/rear panel, and it'll likely be cheaper buying a full case from Adrian rather than a one-off panel set from Schaeffer. I also can't guarantee the availability dates, so if you're in a rush it might be quicker just to complete the Wilba model.

    • Like 1
  7. It's definitely the intention to have duo LEDs for both the "soft" and "selection" buttons. The remainder are MEC illuminated ones, so every button can have an LED. Matias switches have a lifetime of 50million cycles, MEC are 10 million. This version will also have a nice case that I'm working on with Adrian. 

     

    Open questions: switch on the 5V line, yay or nay? How many MIDI outs?

     

  8. Just now, ilmenator said:

    Now you've got me confused: apart from rearranging the buttons (and exchanging the button types), what is it that makes this a SEQ v4+, in the sense of the "plus" featuring something that cannot be had with the regular v4 version? The operation scheme seems pretty much identical to what we already know, doesn't it?

    It will run on an STM32F4, TK.'s label not mine. 

    The operation will barely be different from the Wilba model, apart from having better quality and more refined button functions (as the usage has evolved since 2008), and also the new concept of a selection row. This is the trade off for not making something drastically different, that needs development time TK. can't provide.

     

     

     

    Here's a lefty model:

    08-07-lefty.thumb.PNG.a44f82eb7d79ddc081

     

  9. Current state:

    07-01-1.thumb.PNG.327182997df1237effa6c2

     

    07-01-2.thumb.PNG.3b954b500a1e77cbdf1ef5

     

    Excuse the lame font and generic/misaligned labels!

    This one has fewer switches, but more switches. The idea is to use the first row of keyswitches as "soft" buttons, or General Purpose like in Wilba's. The second row of large switches are for 16 "selection" buttons. This row will change function depending on the state of the 8 buttons around the datawheel. Here you will select the track, parameter layer, trigger layer, mutes etc. As you have 16 buttons, multiple selections (esp. tracks!) can be selected at the same time.  I think it can be done that if the selection button is held down, the datawheel can scroll through 1-16 of that function. On the right, the buttons below the wheel are for transport, record, live, loop etc. The smaller buttons running along the bottom edge are editing commands like copy, paste etc. and edit, menu, pattern, song, utility and so on.

    There's a front-mounted microSD card slot and by request a beat LED.

    TK. will be disappointed that the bottom row are labelled on the underside, but the (rough) panel cutout dictates this, plus the association is clearer that the round rather than the squarish buttons perform these functions. 

     

    This is a rough sketch of the power/USB entry:

    07-01-3.thumb.PNG.a7a4f9690ac619f441e175

    Power switch, USB B for computer and power, USB A for OTG host (here rather connect the B port to a powered hub), and a switch to select for OTG. This way you could still perform updates over USB even if the primary use was as a host. Some sort of USB cable will then connect to the Core located somewhere in the middle. I thought to add a 3.5mm jack (or maybe 1/4") for a footswitch (via a buffer) and wire this to the datawheel board, let's see.

    Adrian brought up a point of switching the data and power lines, and thinking about it I don't think it's wise to have a power switch, because USB normally relies on connecting the power before the data. So is it a problem to use your master USB hub or wall switch instead? Otherwise something like this can be considered, although it seems a lot of effort:

    http://mcs.uwsuper.edu/sb/Electronics/USBswitch/

     

    The DB-25 + PCB is the MBHP Line Driver.

     

    Apart from testing switches and keycaps, and routing up the main PCBs, the next question is MIDI IO. There is space for 16 DINs, but apparently it's inadvisable to use 8 MIDI ports on the same I2C buss. Instead, what's the chance of using the STM32F4 Core's second I2C? Or do we say 4 I, 4 O and 4 I2C outs are enough? There'll be provision to connect the BLM 16*16, maybe other goodies.

    I'm intrigued by KissBox OEM, but the PCB takes up too much panel to be accommodated here. If it was as wide as the RJ45 socket it'd be a contender!

     

     

     

×
×
  • Create New...