• Hi all,

    After a coding marathon week-end, here’s a preview of what’s going to be in the firmware v0.92. Given the amount of changes, it doesn’t deserve a minor number increment, so it’s likely to turn into a v1.00

    UI

    • Patches can be tweaked from the load/save page. In this case, the 4 knobs have the functions assigned to them in the performance page for this patch.
    • The Shruthi-1 can be configured to boot directly on the presets page (aka “presets mode”).
    • Non-blocking ADC scanning increases UI responsiveness.
    • The “mix” and “osc 1” pages have been modified. The sub-oscillator settings are now on the same page as the oscillator 1 settings.

    SYSTEM

    • Different options are available for using the 4 CV: 4 CV ins (assignable in mod matrix — default setting), 32-knobs programmer, or simple mapping to cutoff, param1/param2 for pedals and joystick.
    • External eeproms larger than 64kb are supported, up to 512kb. Note that when a 512kb eeprom is used, the last 64kb block is not used (this is due to the fact that 16-bit arithmetic is used to compute addresses, and that the address space includes the 16kb of the internal eeprom).

    MIDI

    • SysEx Patch request command (0x11 0x00). Upon reception of this command, the Shruthi dumps the currently edited patch. Might be useful for an editor!
    • Support for NRPN increment/decrement.
    • The SysEx backup protocol has been extended to support backing up / restoring more than 16kb of patch data.
    • A bank and program change message is sent whenever a preset is loaded.
    • Bank change messages are handled, to allow patches above 128 to be loaded.
    • Volume change messages (CC 7) are handled.

    SYNTHESIS

    • The shape of the envelope (approximation of an exponential) has been refined.
    • The “2 bits” modulation destination has been removed, since there are now better ways (extra TX pin, shift register out) to communicate digital data with a filter board.
    • A new modulation destination (replacing “2 bits”) allows the attack of both envelopes to be sped up. This settings is particularly useful when velocity is used as a modulation source.
    • The “digital silencing” of oscillators when envelopes have reached zero has been improved. The oscillators are now digitally silenced whenever the VCA destination in the modulation matrix has reached a value of zero.
    • The noise source in the mixer is now refreshed at 40kHz instead of 10kHz, giving it a brighter timbre.
    • The phase counters are now 24 bits instead of 16 bits. This allows more subtle detuning effects between the oscillators, especially in the lowest notes.
    • The audio engine has been rewritten from a “breadth first” to a “depth first” perspective, and as a result, is faster.
    • As a result of the audio engine rewrite, the vowel oscillator can now be used with the noise and sub generators.
    • To make more room for upcoming feature, the “waves” wavetable has been downsampled to 128 samples/waveform instead of 256.
    • New mixing mode (>>4, >>8) allows the oscillators signal to be bitcrushed (sample rate reduction with a S&H).

    CODE

    • Code size optimization saved 460 bytes.
    • The modulation matrix processing code has been simplified.
    • A menu in the UI and code infrastructure is ready to provide filter-board specific menus and parameters in future firmware revisions.
  • Some more testing… and I’ll post the .hex here!

  • awesome!!!! very excited about this!
  • Unreal. Fantastic work, Olivier!

    I am eager to try this out too!

  • quote:
    <<Different options are available for using the 4 CV: 4 CV ins (assignable in mod matrix — default setting), 32-knobs programmer, or simple mapping to cutoff, param1/param2 for pedals and joystick. >>

    is there a way to configure this for the easily available center auto adjusted playstation joystick?
    (so that center position [=~5kohms] would mean zero modulation amount of both cvs)

  • The feature implemented is such that the joystick takes over osc 1 and 2 parameters.

  • oh, cooool!
    so with the centered guy it should be somewhere in the middle by default! awesome.

    so one has to decide for either 32 pot programmer or joystick, not both?
    never enough, i know :D

  • wow ... thanks for all your hard work pichenettes
  • Excellent!

  • oh my oh my!!! this is great! thanks for the hard work!

  • Tested the patch memory thing on a 512kb eeprom, had to make a few changes to make it work. Added the following thing: if you hold the load/save button while you rotate the encoder, it jumps by -10/+10, so it’s easier to navigate through the heap of patches! And if you wonder: I tried first to do this when the encoder is rotated while being pressed, and I found it very awkward…

  • Great thing 512kb eeprom are recognized….I was missing some space to save my own patches without deleting default pichenettes patches….

  • So how does it work… can I just swap the esisting chips with new ones? Do I have to format them like with the SammichSID?

  • Here’s the recommended way:

    1. Backup your patches through a SysEx dump
    2. Swap the chip. At this stage, if you boot the Shruthi, all patches on the new eeprom will be empty. No need to format, the Shruthi recognizes that the eeprom is filled with junk and just displays ? as the first letter of the patch name.
    3. Playback a long .syx file I’ll generate when I’ll have more patches. This will fill 80-100 with new patches and fill everything else with “init”.
    4. Playback your backup to overwrite the original patches with your own.

  • NEw features sound amazing! nice one for ll your hard work!

  • Where can i upload v0.92 ?

  • For now you have to download and build it :) Since it has not been tested a lot, I’d prefer that only the people with the skills to build/upload code have access to it.

  • Oh Yes i understand better !!
    No problem i will wait, i’m not a very good programmer …

  • @pichenettes: thanks a lot for the mini-guide! I’ll see if I can find a bigger eprom…

    Anybody has a suggestion where I can oder these chips in Italy/Germany?

  • Conrad has them on stock.

  • This is great news!

    I got so impatient I started building it. A few questions:

    Which version of gcc do you use? I ask because my firmware_size does not match yours. I'm using gcc-4.4.4, which is the stable version on Gentoo.

    There are inconsistencies between the included music.midi.midifile package and the hex2sysex code - MidiFile vs. Writer, .message vs. .raw_message. I changed those, but I'm sort-of worried that the sysex firmware isn't right. Is it possible to do bad things to the Shruthi with a sysex firmware image?

    Right now, the python code refers to /usr/bin/python2.5, which is a bit old. Things seem to run fine with 2.6, once the header is changed to /usr/bin/python2 and the changes mentionned before are made - is there a reason to use 2.5 specifically?


    I have many other questions, but I want to see how things actually work before commenting :)

    Thanks!
  • Which hex2sysex version are you using ?
    I had a similar issue during the last days (see the "Assigning Sequencers Parameters ..." thread") and after some mail exchange Olivier figured it out there was a minor error in the python script.
    He just changed that last night, so make sure you have the "new" python script or change the file write mode parameter as the comments on github for hex2sysex show.
  • I have an earlier rev controller board,(v0.5) will the upgrade support it?

    And will I be able to add more memory without loosing my patches? (I’m not sure how I would read my patches from eeprom, and write to the new eeprom, via sysex?)

    • My avr-gcc is 4.3.3. Is the firmware size smaller with 4.4.4? If so, I’ll upgrade! With all the recent changes, the moose says 63770.
    • I’ve commited a few changes yesterday to fix the python midifile stuff, including a bug in which it was using w instead of wb to write MIDIfiles (= troubles on windows!)
    • I’ve written a lot of python code in the past for a conservative environment were 2.6 was considered too new, so the boilerplate header I copy/paste everywhere will sometimes reference 2.5, sorry for that. Anyway, the makefile invokes python explicitly (rather than executing the .py file as a script), so it shouldn’t be a problem.
  • The difference between v0.5 and v0.7 is only electrical, the firmware supports both boards. You need to do a SysEx dump of your patches to a computer, then do a dump from the computer to the Shruthi once the eeprom has been changed.

  • On mine, the moose says 63946. I can get a gcc version 4.3.3 easily though. I might try to fiddle with the build parameters to get it smaller, since size is at a premium.

    I saw the latest changes to the midifile stuff, that's exactly it. And actually, it seems the hardware/base.mk invokes hex2sysex.py directly, not python. Replacing that with a direct call to python also works, as you suggested.

    I'll try to upload this when I get home tonight. Thanks!
  • I’ve changed the makefile to invoke the script through python. It’s cool that people start messing with the tools because I have only tested them so far on two systems, and both were running OS X.

  • Under ubuntu 11.04, default avr-gcc is 4.3.5.

    My build is 63782.

  • Also, the midi script works!

  • Could someone do make size_report and send me the build/shruthi1/shruthi1.lss file? I want to see what gcc compiles differently. I fear some stuff will get inlined differently, yielding performance differences.

    Also, 63946 is quite near the 64512 limit – I’ll really have to work hard to squeeze in the last changes I want to make, if I want this to compile on all gcc versions.

  • So, i just need a bigger ATMega thingy, when its released properly ill be able to Sysex it across yeah?

    Of if i buy a bigger ATMega, do i need to use a burner ?

    Nice one =)

  • You don’t need a bigger MCU to do the update. The firmware is compiled for the ATMega644p and no other chip. The update will be done by MIDI.

    What you need to change is the eeprom if you want to benefit from the larger patch memory.

  • Apologies, and thanks. Forgive my noobiness.!

    I socketed all ICs when i built, hurray!

    So should be a doddle to reinstall.

    Many thanks.

  • About eeprom you can have them as samples with microchip site !

  • Hullo kroutshev (from x0x forums!)

    I looked at that – free samples, nice, but feel a bit cheeky. Do they just send them out?

    http://atmel.com/forms/Samples.asp?category_id=&family_id=647&source=getting_started

    Theyre only £1 or so but my usual supplier is out for 2 months

  • Hi Paradigm X !
    yes himself ;-) !
    Yes i think so, i have ordered them yesterday and received an aknowledgment as they have sent me !

  • Cool.,

    How many did you order? Thinking 5 or so.

    Cheers

  • Hmmmm, building with gentoo's avr-gcc 4.3.3, the moose says 64554, that's no good...

    I tried to be as close to the CrossPack-AVR versions as I could, but there's something else going on here. Changing the version of avr-libc didn't change anything, maybe something to do with the "regular" gcc version that was used to build the avr toolchain... I'll keep looking. Or just switch to Windows.

    One thing is clear, I'll be running the official firmware when it's released.
  • Could you please send me the .lss file to check what’s the extra bloat?

  • I just sent them via e-mail. I'll try gcc-4.5.2 in the meantime. Thanks!
  • I’ve carved more in the code size, the moose now says 63522 ; and I’m confident I can get rid of another 512 bytes… Every time I look at the code I spot something new, and there’s a lot of fresh rewritten code that I have not inspected…

    However, this is a bit worrying – the code generated by the latest gcc seems bloated and does some very horrible register choices in some places. I’ll try 4.4.x. It kind of sucks to see such big variations between gcc versions, without having a set of flags to exactly reproduce the behaviour I have here. Didn’t know that I was using a “golden” gcc version :)

    There’s a last big chunk of features I want to push that is going to take 600 or 700 bytes. I’m not sure if it’s going to make it in this version, but they offer quite a lot of interesting possibilities synthesis-wise, so I really hope I’ll carve enough space for them!

  • Oh and there’s now a menu for editing filter mode / topology / cutoff2 / resonance2 for a dual SVF board :) — if I kick my ass to do this board, the “extension port” will be used to drive the analog switches for filter routing.

  • For someone who’s coding experience only ever got as far as: 10 print “Paul was here!” 20 goto 10, I guess i’ll wait for the midi file version!

    Looks like some good work there! And im really looking forward to trying it all out..
    (got your email thanks, i’ll place the order for those parts tomorrow)

  • haha

    I managed to write the theme tune to match of the day in BASIC when i was (ADHD)/younger, but still.

    Looking forward to it. LIking the sound of a dual board.

    =)

  • I was already excited by that new "waldorf" folder with evocative file names, but a dual-filter is just incredible. yay!

    I'm sure the WinAVR/CrossPack-AVR people chose those versions for a good reason. GCC is very variable between versions, and it's not perfectly cross-platform.
  • Also, since commit 249ee95, the code isn't building anymore on my end:

    build/shruthi1/editor.o: In function `hardware_shruthi::Editor::StartMidiBackup()':
    .../shruthi-1/hardware/shruthi/editor.cc:364: undefined reference to `hardware_shruthi::Patch::CheckBuffer(unsigned char*)'
    .../shruthi-1/hardware/shruthi/editor.cc:364: undefined reference to `hardware_shruthi::Patch::Update()'
    .../shruthi-1/hardware/shruthi/editor.cc:364: undefined reference to `hardware_shruthi::Patch::PrepareForWrite()'
    (...more references to those undefined functions)

    The implementations of those functions got removed from the Patch class, does this build on your end?
  • Sorry, forgot to commit the missing file! I’ve just pushed the missing patch.cc

  • Excellent, thanks!
  • And I’ve successfully coded the last feature I wanted to put in there! This is an extremely cheap (300 bytes) feature that brings many new modulation features.

    This feature brings a second page in the modulation matrix (press the modulation matrix button twice) in which you can pick two modulation sources, choose an operation, and the result is available as a new “composite” modulation source.

    Some examples :

    • lfo1, random, multiply -> you get a modulation source equal to LFO1 but with an amplitude which is random at each note.
    • sequencer, env1, multiply -> you get a modulation source equal to the step sequencer, but its intensity follows envelope 1.
    • lfo1, lfo1, multiply -> this modulation source is LFO1 squared (so you can get new modulation waveforms).
    • lfo1, lfo2, max -> the faster LFO is gated and hold by the slowest one.
    • lfo2, seq, xor -> LFO2 polarity is reversed at every note in the arpeggiator pattern.
    • lfo2, seq, max -> when the step sequencer is set to a low value, the LFO takes over.
    • env1, env2, >= -> If envelope 1 has a slow attack and a low sustain, this will create a delayed pulse.
    • env1, env2, <= -> If envelope 1 has a slow attack and a low sustain, this will create an “envelope” which will have a value of 127 during envelope 1’s attack, 0 during its decay, then back to 127.

    I’ve started to play with it and I’m sure there are many hidden gems here, even if there were many Buchla moments (you can set op1 ^ lfo1 -> op2, op2 ^ lfo2 -> op1, and get a nice chaotic modulation source).

  • Whooops. This is more than the usual genius ( if theres a place for usual genius moments then shurely this here is it!) seen here….. thanx man!
    This will be another source if constant inspiration.

  • This is nuts. I love it.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion