MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Expert Sleepers Disting firmware hacking
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author Expert Sleepers Disting firmware hacking
adammokan
Started messing with some silly code to mess up audio using the Disting and put a Github gist up for anyone that has a PICKit3 programmer laying around.

First example is a bytebeat generator/waveshaper. Only tested with basic waveforms so far, but its fun. I know my scaling code for the Z input is garbage, but it works for now. You should be able to replace my `vTrash` variable with any bytebeat code out there that uses the `t` variable for time. But note that I am modulating `t` with the Z pot right now, so mileage may vary. Either way, hope someone gets some ideas from this.

https://gist.github.com/amokan/13acaa559c6868d2a290

There are a couple quick video clips of this on my Instagram feed (user 'adammokan')

http://instagram.com/p/rcVCKsKXzl
os
Cool! I think you're the first to post something. Exciting times.
adammokan
@os - any chance you can throw me a bone on the register settings for the LEDs? I've been messing with it and cannot seem to find the correct way to light up LEDs "1-B".

I've found "1-A" works with:

PORTASET = BIT_3;
PORTBSET = BIT_4;
BrianAndren
adammokan wrote:
Started messing with some silly code to mess up audio using the Disting and put a Github gist up for anyone that has a PICKit3 programmer laying around.



I have an ICD2 laying around. I don't have the Disting yet. What Microchip MCU is in the Disting?
BrianAndren
BrianAndren wrote:
adammokan wrote:
Started messing with some silly code to mess up audio using the Disting and put a Github gist up for anyone that has a PICKit3 programmer laying around.



I have an ICD2 laying around. I don't have the Disting yet. What Microchip MCU is in the Disting?


I think the ICD2 should work. Do you know?
adammokan
BrianAndren wrote:

I have an ICD2 laying around. I don't have the Disting yet. What Microchip MCU is in the Disting?


PIC32MX

I have a PICKit3 with the six pin connector. Not sure about the ICD2.
os
adammokan wrote:
@os - any chance you can throw me a bone on the register settings for the LEDs?

Look in startupSequence() in the hello_disting project. That iterates over the LEDs.
adammokan
Threw together a really noisy, but functional oscillator thing over the past hour. It's pretty weird and shouldn't be interesting at all, but I managed to get some real solid sounds from it. Sounds good with the DPO sending values to X, Y, and Z.

Code/info can be found here - https://gist.github.com/amokan/13acaa559c6868d2a290#file-sinosaur-md
adammokan
os wrote:

Look in startupSequence() in the hello_disting project. That iterates over the LEDs.


Yeah. I found all of that. It does that single light sweep on each side, though. I messed with that loop yesterday to find the secret combo for two lights, but ran out of time. I noticed you seem to be setting register A to zero after the first element of that sequence.

Here is a link to my LED function. Works when `selector` == 0, but not much else. At least it changes so I can tell when I've changed algorithms smile

https://gist.github.com/amokan/288795f6e5d0eb1306e4

So no biggie. You've done enough by creating this awesome little modular sandbox module.
os
I'm giving a presentation about the disting this week at the London Music Hackspace:

http://musichackspace.org/the-disting-eurorack-synth-module-presentati on-with-andrew-ostler-october-9th/
Jamisnemo
This is awesome!

I just got back from vacation and now that my Zorlon Cannon MKII firmware rewrite is on hold, I can start digging into writing some code for the disting!

I guess it's time to move it into my developer rack...

Thanks for the examples and for the hello_disting code!! It's a huge help!
os
Just adding this to the thread for posterity:

ETP
i´m thinking of hacking this little guy too.
i´ve no idea of coding in C. i´ve done some assembler and BASIC coding on the c64. i guess this should help a little bit.

i want to programm a two channel cv clock generator. maybe euclid or something like the "Zularic Repetitor"
or a nice drum synth. should be possible i think..

and i have a couple of questions...

is the original code of disting somewhere for download? for reflash. just in case
can i read out the disting code for backup?
is the mutable module tester necessary? what do you do with that?
is it possible to use snazzy fx sketches?
can i programm it in assembler? better C?

i think this here is my friend for progamming, right?
http://www.amazon.de/Microchip-PICkit3-In-Circuit-Debugger-Programmer- PIC32/dp/B00OAQW7NS/ref=sr_1_1?ie=UTF8&qid=1418481279&sr=8-1&keywords= pickit+3
adammokan
ETP wrote:

is the original code of disting somewhere for download? for reflash. just in case
can i read out the disting code for backup?
is the mutable module tester necessary? what do you do with that?
is it possible to use snazzy fx sketches?
can i programm it in assembler? better C?

i think this here is my friend for progamming, right?
http://www.amazon.de/Microchip-PICkit3-In-Circuit-Debugger-Programmer- PIC32/dp/B00OAQW7NS/ref=sr_1_1?ie=UTF8&qid=1418481279&sr=8-1&keywords= pickit+3


Yes. That PicKit3 programmer will work. Same one I have.

Answers to your other questions -

1) Original firmware can be downloaded here - http://www.expert-sleepers.co.uk/downloads/firmware/disting_firmware_1 _0.zip

2) The stock firmware is compiled already, so you just flash the binary

3) Mutable Module Tester def not necessary. I just use it because I can have it next to me on my desk while coding. Easier than a 4u case swallowing my workspace up.

4) Snazzy FX sketches won't work as they are arduino/atmega based - but you could use them as a rough outline writing C code for the Microchip processor.

5) Assembler is an option for sure. I'm sure you found it, but the best way to start is with 'base' project OS pushed to github - https://github.com/expertsleepersltd/disting

Hope that helps!
ETP
yes you helped me thumbs up

thank you!!
daluxer
Ha, glad the thread is back.

A CV record would be nice to see in disting. Os told that it is possible.

I'm thinking something like : Z - Position(?) X - input signal, Y - start/stop trigger, A - output and B ..- inverted out?
adammokan
daluxer wrote:
Ha, glad the thread is back.

A CV record would be nice to see in disting. Os told that it is possible.

I'm thinking something like : Z - Position(?) X - input signal, Y - start/stop trigger, A - output and B ..- inverted out?


Definitely possible. I started messing with this a bit one morning, but I don't believe I saved the code when getting a new laptop. Memory is limited, but depending on how you store the data, a few seconds is possible. I really need to grab another Disting to use as a development module and mess with this more. I just hate having to take the Disting out of the rack to access the programming pins and reset button.
daluxer
great news adam. I'm not sure if I am capable of programming it but I should pick up a programmer aswell..lots of nice things can be done! smile
DMR
My understanding is that while a compiled copy of the original firmware is available, the source is not? I understand if Os doesn't want to release the source of each module "program", but it would be convenient if compiled versions of the individual programs were available so hackers could mix and match custom and factory programs in some manner. Also, perhaps future versions of the module could allow for updating of the firmware over audio as the Mutable Instruments modules are.
bgf
Just found out about disting. Had been looking at some of the arduino boards. Some questions:

* I want to write some CV processing routines. Are the Inputs and outputs accurate enough for CV work? I assume so, but all the spec are for audio processing. What's the DC range of the I/O?

* It seems the free compiler outputs completely un-optimized code, and the optimizing compilers are punishingly expensive. Is the 10X performance hit really not a problem for the things we want to do with this board?

thanks!
os
Most of the disting's functions are CV processing. The range is about ±10V.

The free compiler supports gcc -O1, which is pretty good.
bgf
os wrote:
The free compiler supports gcc -O1, which is pretty good.


Ah - I did not realize this. I assumed optimizations were completely off, which is kind of terrible. -O1 doesn't sound so bad. thanks.
bgf
Has anyone ever hacked the disting hardware to add more inputs or outputs? I'm guessing it's not so easy, as (unlike the Arduinos) there are probably no convenient headers for finding the peripheral buses.
adammokan
bgf wrote:
Has anyone ever hacked the disting hardware to add more inputs or outputs? I'm guessing it's not so easy, as (unlike the Arduinos) there are probably no convenient headers for finding the peripheral buses.


No headers are available and everything is SMT. Not saying you couldn't try if you were insane enough - but if you want to hack at the hardware level with this chipset, just grab a Pic32 dev board, some opamps, pots, and a codec chip.
adammokan
bgf wrote:
os wrote:
The free compiler supports gcc -O1, which is pretty good.


Ah - I did not realize this. I assumed optimizations were completely off, which is kind of terrible. -O1 doesn't sound so bad. thanks.


Never had any issues with the free compiler regarding optimization (and no, they are not 'completely off'). Granted, I don't care that much because I deal with code optimization all day at work and do this for fun, but I've never felt anything I developed on the Disting was suffering due to the compiler.
adammokan
I've not tried it yet because it seems like every time I make changes, my ARM gcc toolchain shits the bed - but found some info on configuring PIC32 for gcc here: http://wise-ware.org/wiki/
bgf
os wrote:
Most of the disting's functions are CV processing. The range is about ±10V.


Does "about 10V" mean a precisely calibrated voltage that is near 10V? Or does it mean an arbitrary un-calibrated voltage than is around 10?

Obviously the former would mean one could output pitches and hit 1V/Ocatve. I'm guessing that's the case.
os
The hardware itself is not calibrated. The factory firmware is calibrated in software.
bgf
os wrote:
The hardware itself is not calibrated. The factory firmware is calibrated in software.


If one writes their own firmware do they then need to re-calibrate? Or is the calibration information stored in some persistent location that will survive hacked firmware?
os
It's in the flash. If you use the provided project file, it has the necessary settings to preserve the relevant area while flashing the new code.
bgf
If I succeed in developing some disting firmware, what would my friends need to install my firmware? Obviously one of the little pic programmers, but what software? Hopefully not the IDE?
os
Yes, the IDE. It's free.
bgf
os wrote:
Yes, the IDE. It's free.


Cool. I realize it's free, but I assume that like most IDE's it will be a slight pain for my friends to configure etc... No biggie....
Jamisnemo
There's also a piece of software called MPLAB IPE that gets installed when you install the IDE that will let you write the firmware to the module without having to set up the project in the IDE.

This site says you can choose to install either the IDE, or the IPE, or both using the normal installer. ymmv:
http://microchip.wikidot.com/ipe:installation

Make sure they get a PICKit 3 if they do get one. I don't think the PICKit 2 supports the PIC32MX line of chips like the one that's in the disting... I may be wrong though...
bgf
Jamisnemo wrote:

This site says you can choose to install either the IDE, or the IPE, or both using the normal installer. ymmv:
http://microchip.wikidot.com/ipe:installation


oh - cool. that's great. tx.
bgf
I notice these pickit3 vary in price quite a bit. Anything wrong with getting a cheap ($50) one? Also, some seem to come with a zif socked for device programming. Is this of any use with disting, or is disting programming done throught the pickit3 pod?
bgf
Just checked out “hello_disting” for the first time.

It seems the programming model is nice and simple: every time around the loop you read a codec frame, write a codec frame, read the ADC, do your stuff.

What happens if you take too much time “doing your stuff” and miss a codec frame? Does it silently fall on the floor? Or do you need to invoke some error recovery to get things moving again? Since I’m interested in CV processing, don’t want to have to care about missing a sample…

For CV applications, it seems sensible to downsample the codecs to a lower SR so that there is more processing time, yes?

It’s probably overkill, but in a very complex application it would be nice to run the tight processing loop in a different schedule from code that scans pots and maybe does expensive operations to update processing parameters. If we had an OS we would use threads, here we would presumably use an ISR.

So – is it possible to run the codec service loop from interrupts? Or, more to the point how would one figure out how to do that? Reading the pic documentation?
bgf
oops - one more question on hello_disting. The readme tells how to avoid nuking the calibration table, but there does not seem to be any documentation on using the calibration table.
bgf
Jamisnemo wrote:

This site says you can choose to install either the IDE, or the IPE, or both using the normal installer.


If you use the IPE, do you still need to manually exclude the calibration table memory addresses? Or is that info compiled into the binary already? In other words, does only the firmware author need to worry about nuking the cal table, or does the end user also need to worry about that?
os
Quote:
What happens if you take too much time “doing your stuff” and miss a codec frame? Does it silently fall on the floor?

No, it's fine. The codec is serviced from an interrupt.

Quote:
but there does not seem to be any documentation on using the calibration table.

Correct.

Quote:
If you use the IPE, do you still need to manually exclude the calibration table memory addresses? Or is that info compiled into the binary already? In other words, does only the firmware author need to worry about nuking the cal table, or does the end user also need to worry about that?

It's the MPLAB project file that contains the information about maintaining the calibration data.
bgf
Don't know how I missed the codec ISR at the bottom of main ;-)

I think I would like to access the calibration table so that I, too, can output 1V/oct. Short of documenting it, could you give me a hint? Judging from the size it must be a lookup table. I guess it can't be too hard to "hack" it.
os
I've deliberately not published any details of the calibration process. I was interested to see if anyone could come up with something better than I did.
bgf
os wrote:
I've deliberately not published any details of the calibration process. I was interested to see if anyone could come up with something better than I did.


That's cool. I guess the problem for people like me is that I don't have a DVM that is accurate enough to measure what comes out. And if I want my friends to use my software they certainly won't.

I'm probably over simplifying. I would have thought the DACs are pretty linear, so all you would need is the output voltage for 0, 8000, ffff (if that) so the software could adjust gain and offset.
bgf
I guess the entire PLIB.h is deprecated? There seems to be some controversy in PIC32 land about this. In any case, to get rid of tons of warnings I needed: -D _SUPPRESS_PLIB_WARNING.

Also, there was this: -D _DISABLE_OPENADC10_CONFIGPORT_WARNING. Is that something I should care about?

Lastly: Interrupt priority IPL3 is deprecated. Specify as 'IPL3{AUTO|SOFT|SRS}' instead.

The Internets suggest the software won't even work unless you make the requested change?

This is all with the current compilers that are available for download.
Dogma
Ive been thinking - how many more things could be done if TWO distings where programmed for as one - so disiting a out disting b in. SO Quad stuff would be a lot easier - DIsitings as we know are needed by a factor of at least 2 anyway!
bgf
Dogma wrote:
Ive been thinking - how many more things could be done if TWO distings where programmed for as one


Some hack to send a high-speed serial link from one to the other would be pretty sweet. Or an I/O expander like on some of the other ES modules...
Dogma
OS could this be a thing? IM going get another shortly and most systems seem to have 2 - what say you? smile
os
Quote:
I guess the entire PLIB.h is deprecated?

So it seems. Got hit with that the other day. I don't think it's anything to worry about - nobody's going to force you to upgrade your compilers (this isn't Apple).

Quote:
Some hack to send a high-speed serial link from one to the other would be pretty sweet.

That would be quite a hack, but you could mod the boards to expose a UART or something.
bgf
os wrote:
Quote:
I guess the entire PLIB.h is deprecated?

nobody's going to force you to upgrade your compilers (this isn't Apple).


Ha - luckily is seem Microchip keeps all the old compilers available for download.

btw: In my day job I code for iOS. Was just forced to upgrade Xcode to support the new iOS. Now it crashes every time I use the search function ;-(
bgf
There isn't any convenient way to hook a serial port to a Disting is there? Would be kind of handy to print to a console like you can on an Arduino....
os
You could solder a wire onto the board - hijack one of the LED lines, maybe.
bgf
I notice that I am able to plug the pickit-3 into the disting in either orientation. How do I know which is the right one?

The pickit has an arrow on one end. The disting doesn't seem to have any orientation marking. The PCB has printed on it "pickit 3 or similar goes here", but no little matching arrow.

>> I just watched your video. In the video it looks like the LEDs on the pickit should face the same way as the ICs on the PCB.
os
Like this:



It honestly never occurred to me that anyone would plug it in a different way!
bgf
Thanks - that is the is the orientation I seemed to see in the video. Now I'm dealing with the infamous "pickit3 doesn't always work in 64 bit windows". Or whatever. It works fine in my (work) mac, but not in my home hacking computer ;-(

Update - all working now. tx.
bgf
When you compile hello disting with the current C32 compiler, you get a bunch of warnings. I've been struggling with how to properly declare the ISR.

This works, and gets rid of the warning:

void __ISR(_SPI_1_VECTOR, IPL3SOFT) SPI1InterruptHandler(void)

(I added "soft". Presumably before the default was "auto", but soft is better here. Note also that it is not case sensitive, but since everyone uses UC, I did that).

According to the manual, this should be the way to do it, but I couldn't get it to compile:

void __interrupt(_SPI_1_VECTOR, IPL3SOFT) SPI1InterruptHandler(void)
os
You're better off just downloading the old compiler.
bgf
I'm thinking of trying to reverse engineer the factory calibration table. The data in flash looks like four gains and four offsets, just like one would expect.

It's sort of attractive to try and re-use this data, since I don't own a precision DVM or precision voltage reference. Looks like one can obtain good voltage references for cheap, however, So I can always fall back on that. Or have some other clever idea...
pippen
I just bought a Disting and try it. I downloaded the code framework and take a look. Also I viewed the presentation video at London Hackspace but I'm spanish speaker and got less than half from explanation.

My first question is: if I write some logic in the framework project and flash it to the Disting, all 16 default programs will be overwritten or I can replace one specific factory program?

All the red underlined marks (for example "ReadADC10" it is not recognized) are due to my compiler version as said before in this thread? Now the project is unable to load following files:

#include <stdio.h>
#include <stdlib.h>
#include <xc.h>
#include <plib.h>

Thanks.
os
You need to install the older v1.3.1 compilers.

If you flash the disting, it will completely replace the factory code i.e. all the algorithms.

The code on github hasn't been updated yet for the v2 distings, which have a slightly different PIC.
pippen
Thank you for your answer.

You say that if I have Disting v.2 I will need a different project than it is on Github now if I understand.

But despite of buy the module few days ago on London Modular and check an item that was named as "Disting v.2", the one that they sent shows "Disting 1.1" printed on the PCB. I don't know if it is a mistake from London Modular or you have take advantage from old PCB's for any new module. The microcontroller on mine is MX170F256B.

Can you assure I can flash the public code on my module and if I needed it is possible to reflash the stock firmware?

Thanks.
os
This batch of mk2 distings used v1.1 PCBs. The difference is the MX170 processor.

The public code will not work on this device yet, but once it does, it will be possible to flash back to the stock firmware.
auxren
Just put 2 and 2 together and realized I've been programming PIC32MX for work and have the PicKit3 and the Disting runs off a PIC32MX... This is about to be awesome!

So the source code for the original firmware isn't available anywhere as a reference?
os
The full firmware isn't but a shell project is available which covers all the configuration, knob reading etc.
warmfuzzy
Hi

Someone posted a link to the disting firmware above as http://www.expert-sleepers.co.uk/downloads/firmware/ and then some version number which looks like 1.0. But I can't seem to navigate there from anywhere on the Expert Sleepers site.

Is this the latest firmware that will work with mk1?

Cheers
Scott
os
Yes, firmware v1 is what you want for a mk1 disting.
auxren
To write code for the MkII disting, do I just change the processor in the shell project to an MX170? Anything else?
os
Pretty much, though you may have to fudge around the lack of support in the older Microchip libraries for the newer MX170 processors.
auxren
Thanks! Any bones you can throw as to getting started with an algorithm? Never did this kind of coding before. Or just some tips on determining the incoming audio's frequency.

Also, my own code would obviously replace all the algorithms in the device, so I wouldn't be able to replace 1 algorithm for my own while keeping the rest, right?
auxren
nevermind on the algorithm replacement, I missed an above post.
os
http://www.musicdsp.org is a fun place to poke around.
auxren
Thanks! Sorry for all the questions, but, what is the maximum possible value read from the ADC (inL and inR) and what is the maximum value written to the DAC (outL and outR). Can those values go negative? Or are they centered around a positive value?
os
They're signed 24 bit values.
jbox5
Please excuse me if I'm just being dumb, but I can't seem to see the 1.3.1 compiler on their site anywhere. Only the latest one seems available. Does anyone have a link (or failing that, the file itself)?
os
http://www.microchip.com/pagehandler/en-us/devtools/mplabxc/home.html

Then click "Downloads Archive".
bgf
os wrote:
You need to install the older v1.3.1 compilers.

If you flash the disting, it will completely replace the factory code i.e. all the algorithms.

The code on github hasn't been updated yet for the v2 distings, which have a slightly different PIC.


I'm using 1.34. I did have to modify the source code a tinny but. probably not recommended, but just thought I would mention...
bgf
I notice that the values read from the Z ADC don’t span the full range from 0..1023. On one disting I observed 157..934 with no CV input and moving the knob through the full range.

Many times it’s important that you get an effective “full range” from a knob. In the thing I’m working on now the knob selects a probability from 0..100 and it’s important that it get all the way to those two numbers.

It seems reasonable, then, to “expand” the range so that it will in fact hit 0 and 1023. In other words “calibrate” the z input based on a pessimistic guess as to what the tolerance of these devices actually is. Say assume minimum of 200 and max of 875.

Any thoughts on this?
os
Yes, basically. The pot has quite a loose tolerance, so be pessimistic with your range adjustment.
ssjog
phase-shifting


https://ccrma.stanford.edu/realsimple/DelayVar/DelayVar.pdf

lets make a baby/phaser
bgf
ssjog wrote:
phase-shifting


https://ccrma.stanford.edu/realsimple/DelayVar/DelayVar.pdf

lets make a baby/phaser


You don't want a fractional delay line for a phaser. You want to cascade several all pass filters and then sum the output of that with the original input.

I learned how to do it from this old classic: http://www.amazon.com/Musical-Applications-Microprocessors-Hal-Chamber lin/dp/0810457687
ssjog
Quote:

You don't want a fractional delay line for a phaser. You want to cascade several all pass filters and then sum the output of that with the original input.

I learned how to do it from this old classic: http://www.amazon.com/Musical-Applications-Microprocessors-Hal-Chamber lin/dp/0810457687


Right! The allpass filter approach is what is he describes in the paper (although its mostly about delay effects).

"Phasing with First-Order Allpass Filters" starts on page 22 or something..

I wrote a VST based on it a few years ago, sounded pretty good cool
jfberma
Just got a MK3 (had a MK1 for a while, loved it).

I'm curious about adding custom algo's via micro sd.

I assume without access to the firmware source, there is no way to add a custom algo to, say, one of the placeholder slots of the second bank so that it co-exists with the algos that are already present?
bgf
jfberma wrote:
I assume without access to the firmware source, there is no way to add a custom algo to, say, one of the placeholder slots of the second bank so that it co-exists with the algos that are already present?


As of now there is no way to mix and match algos.
jfberma
Figured. Thanks. I'm sure those empty slots will be populated with sweet algos.

I would love a user writeable quantizer smile
wminor
I have a mk3, and am keen to try my hand at hacking it.

os: the website says that the stuff on github hasn't been updated for mk3 yet. Any idea when that might happen?

Also, will I be fine using microSD to get my code on to the module, or would it be better to get a programmer?
os
No idea when I'll get around to updating the github code for mk3, sorry.

You'll want to use a programmer for serious development. The PICkit3 works but I recommend the ICD3.
wminor
os wrote:
No idea when I'll get around to updating the github code for mk3, sorry.

You'll want to use a programmer for serious development. The PICkit3 works but I recommend the ICD3.


Thanks! Totally understand about the update, appreciate how busy you must be running your business.

Other fellow disting hackers: am I out of luck until the stuff on github is updated, or might I be able to figure stuff out myself and make some progress anyway with what's available at the moment? This is my first foray in to any kind of embedded programming. I know C but I've only ever written relatively higher level code for Linux or OS X.
wminor
Also, if anyone can explain to me why I might prefer the much more expensive ICD3 programmer over the PICkit3, I'd love to hear what the differences are. Again, I have no experience with this kinda thing, so reading the specs on websites doesn't tell me a great deal.

I'm having so much fun being a n00b again with so much to learn applause
os
The ICD3 is about 5-10x faster at flashing the chip. That time really adds up if you're doing a lot of changes.
bgf
wminor wrote:

Other fellow disting hackers: am I out of luck until the stuff on github is updated, or might I be able to figure stuff out myself and make some progress anyway with what's available at the moment? This is my first foray in to any kind of embedded programming. I know C but I've only ever written relatively higher level code for Linux or OS X.


Well, it's difficult to say. But from reading the specs I would say that the mk3 is going to be different enough from the previous ones that the old code won't work at all. So you would have to reverse engineer the hardware schematic, get some data sheets and figure stuff out yourself.

I AM quite experienced with that kind of work, and even I would say it's difficult.
bgf
os wrote:
The ICD3 is about 5-10x faster at flashing the chip. That time really adds up if you're doing a lot of changes.


On the other hand, I develop all my algorithms on my desktop PC, so I don't fire up the pickit3 very often. The programming time is not important to me.

Once everything works perfectly on the PC, I try it out on the disting with the Pickit. I've found this works very well.
wminor
bgf wrote:
wminor wrote:

Other fellow disting hackers: am I out of luck until the stuff on github is updated, or might I be able to figure stuff out myself and make some progress anyway with what's available at the moment? This is my first foray in to any kind of embedded programming. I know C but I've only ever written relatively higher level code for Linux or OS X.


Well, it's difficult to say. But from reading the specs I would say that the mk3 is going to be different enough from the previous ones that the old code won't work at all. So you would have to reverse engineer the hardware schematic, get some data sheets and figure stuff out yourself.

I AM quite experienced with that kind of work, and even I would say it's difficult.


Thanks. Yeah I came to more or less the same conclusion after a bit of digging. Luckily I hadn't dropped the cash on a programmer when I realised that.

In the mean time I've been getting my feet wet with a Teensy, which has been a fun and easy way to take some first steps into embedded programming.
ssjog
Guinness ftw!
ssjog
Hallå!

vorshtein_disting firmware is currently a voltage controlled phase shifter.

Using MPLAB X IDE /w xc32 v1.32 it should build and run correctly on a disting mkII.

https://github.com/ssjog/vorshtein_disting

cheers /sebastian Guinness ftw!
kjnilsson
Is open sourcing the complete mk3 firmware a possibility at all?
deadvolume
Hi Guys,

I've pretty much locked myself in my room for roughly 6 weeks working on a new firmware for the Disting mk2, it's almost ready to be released into the wild!

This has been my first foray into C programming (and DSP for that matter!), quite a learning experience and (mostly) a lot of fun.

There are around 30 modes (I think), including:

Compressor;
Knob recording envelope/LFO;
Chord oscillator with inversion control and user slots;
Live input recording sequencer for CV with pattern switching;
Dual channel trigger sequencer with ratcheting and pattern switching;
Crossfader/binaural(ish) panner;
Stereo multitap meta delay;
Dual channel quantiser with harmony and independent modes;
ADSR envelope with preset types and macro control;

...aaand all the usual handy maths/logic LFO gubbins, mainly crammed into mode 1-a.

Here is a rough demo of the delay:
https://soundcloud.com/deadvolume/disting-diy-firmware-delay-mk2

Video demos are in the works, once I've done a couple of these I'll get it put out there!
EATyourGUITAR
can we have a dual linear slew mode added to the official firmware? I think this would be super easy to write. the code is basically already there.
pisrecords
deadvolume wrote:
Hi Guys,

I've pretty much locked myself in my room for roughly 6 weeks working on a new firmware for the Disting mk2, it's almost ready to be released into the wild!

This has been my first foray into C programming (and DSP for that matter!), quite a learning experience and (mostly) a lot of fun.

There are around 30 modes (I think), including:

Compressor;
Knob recording envelope/LFO;
Chord oscillator with inversion control and user slots;
Live input recording sequencer for CV with pattern switching;
Dual channel trigger sequencer with ratcheting and pattern switching;
Crossfader/binaural(ish) panner;
Stereo multitap meta delay;
Dual channel quantiser with harmony and independent modes;
ADSR envelope with preset types and macro control;

...aaand all the usual handy maths/logic LFO gubbins, mainly crammed into mode 1-a.

Here is a rough demo of the delay:
https://soundcloud.com/deadvolume/disting-diy-firmware-delay-mk2

Video demos are in the works, once I've done a couple of these I'll get it put out there!
wow ! applause
MUFF WIGGLER Forum Index -> Music Tech DIY  
Page 1 of 4
Powered by phpBB © phpBB Group