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

hexinverter/ACXSynth MIDI2CV firmware: 5.7.3
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2, 3 ... 10, 11, 12  Next [all]

What else to add/change? (choose most liked or necessary)
Program unit via Program Change or SysEx instead of keys.
19%
 19%  [ 12 ]
Classical ACXSynth mode
1%
 1%  [ 1 ]
Arpeggiator
56%
 56%  [ 35 ]
S&H generator
3%
 3%  [ 2 ]
Completely different operation mode like MIDI CC or trigger controller
12%
 12%  [ 8 ]
Digital scale and zero adjustment (may be miserable)
4%
 4%  [ 3 ]
(Self-) test mode (please explain)
1%
 1%  [ 1 ]
Total Votes : 62

Author hexinverter/ACXSynth MIDI2CV firmware: 5.7.3
rpocc
This thread is dedicated to my version of firmware for Hexinverter.net MIDI2CV interface or original ACXSynth version.

Discussion was started at this post and my last post about firmware is here.

Description
5.x firmware is more stable than original firmware and offers number of adjustable parameters and new features. Also, voices in Poly4 mode are assigned in different way. 10 July 2014 it became an official firmware for hexinverter.net MIDI2CV modules and also became open-source.

Current version: 5.7.3 (Official version)

Features:

  • Original “hanging notes” problem is solved.
  • Voices in Polyphonic mode are assigned serially (exactly as implemented on DSI Prophet 2008).
  • CV2 Out can be used as output for assignable MIDI Control Change or Aftertouch.
  • Hold Pedal is now supported in Monophonic and Polyphonic modes.
  • Pitch Bend is supported in all modes.
  • All Sound Off and All Notes Off messages are processed.
  • Clock output is working at 1–24ppqn (programmable).
  • Legato play and retrigger are supported. (up to 8 notes are stored).
  • 2 Velocity curves (linear/Exponential).
  • up to 8-voice system with polyphonic velocity can be built with more units connected via MIDI-splitter.
  • Number of available voices can be limited to any number of voices (2–4/2Ã¢â‚¬à €œ8). Available voices are mapped to corresponding number of CV/Gate outputs starting from CV1 / GATE1.
  • All parameters can be stored into EEPROM.


Download firmware
You can find download links and version information on the project page

How to update
Update via MIDI is not possible at this moment.
You need:

  • new PIC16F88 MCU chip in DIP18 package. (you can use original chip, but you can't backup its contents because it is protected)
  • IC Extractor or little screwdriver
  • Programmer such as SI Prog, PicKit3 etc and necessary adapter hardware (board with ZIF/DIP-sockets, breadboard and Dupont wires etc)
  • Software that supports your programmer and able to read text .hex files

There is possibility that preprogrammed chips will be available at hexinverted.net store in the future, but at this moment it isn't.
There is also possibility that I will supply chips myself, but I'm live in Russia and our national post service is really weak, so I don't want yet to take a risk.

Enjoy, have fun, donate.
heapish
Ace! I've just ordered this kit.
logicgate
I don't recall right now, but the Hex MIDI2CV has no ISP connector?

I have USB tiny programmer...
raisinbag
logicgate wrote:
I don't recall right now, but the Hex MIDI2CV has no ISP connector?

I have USB tiny programmer...


No connector. If there is a way to use USBtiny that would be great (because I have one). Looks like ill be getting a pic3. (Ps do you have the midibud yet?) hyper
rpocc
raisinbag wrote:
logicgate wrote:
I don't recall right now, but the Hex MIDI2CV has no ISP connector?

I have USB tiny programmer...


No connector. If there is a way to use USBtiny that would be great (because I have one). Looks like ill be getting a pic3. (Ps do you have the midibud yet?) hyper


USBtiny is for AVR controllers only.
Monobass
cooool.. just need to find time to build the thing now!
mOBiTh
rpocc wrote:
EMwhite wrote:
Along the same lines, what input data lines might be available for, perhaps, a diode and additional switch. We are all handy enough to build this, adding a few passive components shouldn't be that tough?


Well, there is two free ports: RA6 (15) and RB5 (11), but in order to use it you have to solder wire right to the MCU's socket leg and add necessary pull-up 10k resistor.

Let's name it as protection switch and assign it to RB5 (pin 11).

This is how I see it:
This switch must be open (Vcc to pin) in order to accept programming keys and closed (GND to pin) to deny it. But there is problem with backward compatibility. Ports are not pulled down or up by default and because of that I can't write same firmware that can work with hardware protection and without it. Pin state becomes unpredictable without pulling due to interference. I don't want to start two additional forks from my own fork and maintain them both in parallel.

Instead of this I can add protection support OPTION to the list of adjustable parameters, assign yet another key to toggle switch support on and off and ignore pin when support is off. There comes next problem: It makes no sense if parameter save/load is not implemented.
So, to add support for programming protection switch, I should also add EEPROM save/load, additional MIDI Channel# parameter, Protection on/off parameter etc.

So, it is decent amount of work guys. I will take your requests into account but such functionality should be released in complex within same version. So, right now I prefer to leave parameter adjust interface as it is and when time will come you'll get your switches, presets and maybe iven chord play or another weird function.



I'm definitely up for adding an extra programming switch and whatever else is required to save parameters, if the toggle switch option isn't an option!

In the mean time a 'vanilla' version is also essential, I think, with no active function keys, as it'll be almost impossible to stop a sequencer playing the function keys by mistake.

The reason for this is that the sequencer often defaults to low notes when programming, requiring you to scroll up through the octaves to desired notes, which will inevitably cause 'collisions' with function keys. Also, it's impossible to stop an arpeggiator playing certain notes, so the module won't be compatible with arps if the function keys are always active...

Here's another idea:

If the midi channels are set to 1-4 - couldn't the function keys be active only on midi channel 5? A waste of a midi channel perhaps but safer from a control point of view.

A separate programming mode is definitely the most desirable option though...
rpocc
mOBiTh wrote:


I'm definitely up for adding an extra programming switch and whatever else is required to save parameters, if the toggle switch option isn't an option!

In the mean time a 'vanilla' version is also essential, I think, with no active function keys, as it'll be almost impossible to stop a sequencer playing the function keys by mistake.

The reason for this is that the sequencer often defaults to low notes when programming, requiring you to scroll up through the octaves to desired notes, which will inevitably cause 'collisions' with function keys. Also, it's impossible to stop an arpeggiator playing certain notes, so the module won't be compatible with arps if the function keys are always active...

Here's another idea:

If the midi channels are set to 1-4 - couldn't the function keys be active only on midi channel 5? A waste of a midi channel perhaps but safer from a control point of view.

A separate programming mode is definitely the most desirable option though...


See attached file with version specially for you.
It has aditional parameter: program lock.
As you press C#1 key, all functional keys become immediately disabled till next hardware reset or Reset All Receivers MIDI message.

Concerning your proposal, I find it oversofisticated. At first, if current channel is 13 then there will no be room for programming channel. Also, all channel messages are processed in the way when channel number is filtered first and further code do not take channel into account at all.
monstrinho
At the moment I don't have a PIC programmer (and honestly, it's pretty far down my list of things I need to buy), but I would be interested in purchasing a chip with this firmware if they are offered for sale (or if someone with a programmer could burn an extra one). I'm guessing there must be at least a few people in the same boat, so if someone were to put together a small run of chips, it would be hugely appreciated.
waveglider
I will be offering burned PIC chips to anyone who is interested.

The price would be $10 shipped in the US, shipping would be more to the rest of the planet.

Please PM me if you are interested.
mOBiTh
rpocc wrote:
mOBiTh wrote:


I'm definitely up for adding an extra programming switch and whatever else is required to save parameters, if the toggle switch option isn't an option!

In the mean time a 'vanilla' version is also essential, I think, with no active function keys, as it'll be almost impossible to stop a sequencer playing the function keys by mistake.

The reason for this is that the sequencer often defaults to low notes when programming, requiring you to scroll up through the octaves to desired notes, which will inevitably cause 'collisions' with function keys. Also, it's impossible to stop an arpeggiator playing certain notes, so the module won't be compatible with arps if the function keys are always active...

Here's another idea:

If the midi channels are set to 1-4 - couldn't the function keys be active only on midi channel 5? A waste of a midi channel perhaps but safer from a control point of view.

A separate programming mode is definitely the most desirable option though...


See attached file with version specially for you.
It has aditional parameter: program lock.
As you press C#1 key, all functional keys become immediately disabled till next hardware reset or Reset All Receivers MIDI message.

Concerning your proposal, I find it oversofisticated. At first, if current channel is 13 then there will no be room for programming channel. Also, all channel messages are processed in the way when channel number is filtered first and further code do not take channel into account at all.


hey mate

didn't see this before somehow - great idea - set and forget.

will give over the next few days

cheers!! 8_) 8_) 8_)
heapish
waveglider wrote:
I will be offering burned PIC chips to anyone who is interested.

The price would be $10 shipped in the US, shipping would be more to the rest of the planet.

Please PM me if you are interested.


I'minterested but iI've only just got my kit so I'd rather try it out first
neilbaldwin
I have a Pickit3 so could possibly offer PICs to UK-based wigglers.

PM me if there's any interest and I'll figure out a price. I'll do it at cost, not interested in making anything on it.

I should probably order a kit myself though first. lol
EMwhite
Velocity question...

I noticed that on the 4.0 stock firmware that when I am using Velocity in Mono mode if I hold one key then strike the 'next' key, that Velocity is sent correctly; however when I release the first key which is no long playing (since I'm in Mono), Velocity is trashed and the Filter (in my case) cutoff drops way low.

Not sure if the code is using release velocity also as a new event and changing the voltage accordingly but it's not very useful or friendly.

Has anybody else noticed this, and can you tell me if the latest 'alternative' firmware does this?

Thank you.
elmegil
I noticed and posted about it on the release thread. Totally hoses legato playing when trying to use velocity.

I found a partial workaround was to run the velocity into a sample & hold that is triggered from the keyboard trigger, but that is only a bit better.

I have no idea if the alternative firmware is working on this problem or not.
EMwhite
Grrrrrr.... but thanks for the confirmation.
rpocc
As I said earlier, I tried to analyze my version (5.5) about velocity behaviour and it seems to work OK with no drops. Actually, the code was revised deeply and there is not much left from the original. Only hardware-dependable things like DAC commands, switch processing, etc.
EMwhite
Any update on firmware? Is 5.5 the current, and assumed final version that you are happy with and no known bugs?

I ask because I just ordered another two Midi2CV board sets and am going to order a few PICs for the 3 of them.

Thanks!
mOBiTh
Sad to report that my v5.3 was crashing left right and centre the other day.

It seemed to be repeatable but I was in the middle of making a track so didn't/couldn't investigate - just swapped to qMI instead, which worked fine.

will do some testing over the weekend if I can and if I can repeat it I'll generate a midi file for analysis. hmmm.....
waveglider
I now have PIC chips flashed with v5.5 available.
rpocc
Quote:

Any update on firmware? Is 5.5 the current, and assumed final version that you are happy with and no known bugs?
I ask because I just ordered another two Midi2CV board sets and am going to order a few PICs for the 3 of them.
Thanks!


I have no ideas for rapid update. Right now I'm working on patch transfer from my old Juno-G synth to Fantom-X. Also I started to develop some sofisticated solution to make MIDI firmware updates possible, but I simply have no time to test it on-platform.

The version 5.5 can be considered stable release, but if someone will report detailed bugreports in this thread, I will fix them. (Actually I'm quite tired to pull the module out and put it back again instead of using it to make some music. smile)

Quote:

Sad to report that my v5.3 was crashing left right and centre the other day.

It seemed to be repeatable but I was in the middle of making a track so didn't/couldn't investigate - just swapped to qMI instead, which worked fine.


I'm looking forward to get more detailed information. BTW, what qMI is anyway?
rpocc
By the way, I found cool Microchip application that can program chips with PicKit3 very easy. It called PicKit3 Stand-alone Programmer..
Above is direct link, but you also can examine Archive page.

This is the video explaining this application.
heapish
Anyone burnt any of these. 90% built mine this afternoon.
marfoski
I have built the standard (the original project from ACX) MIDI2CV and it works perfectly with the new firmware v.5.5. There's only a slight annoyance: the POLY4 and POLY1 positions are swapped on the switch, with POLY1 on the middle position, while MONO it's OK. It can be my fault but nonetheless with the original firmware the positions are correct. Apart from that, it's really a big improvement: spasiba Dmitry!
marfoski
Maybe I have been a little too enthusiastic because I hadn't tried the programming keys (C1-F1) and none of them seem to work ... sad banana
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2, 3 ... 10, 11, 12  Next [all]
Page 1 of 12
Powered by phpBB © phpBB Group