ADDAC207 - Firmware Upgrade Process: Issues / Questions
Agreed! ADDAC, that would be extremely helpful.Well, that's kind of why I requested an updated manual that reflects the latest changes.... very frustrating There's no coherent changelog to be found...
I was confused if I needed to do an additional upgrade since December since its not clear what is new. I haven't run into any issues.. so is it a new feature (doubt it) or a debug on something I don't know about, but should?Here's the direct link to our Firmware Upgrade OSX App (vs: J9) - last update March 2nd, 2015:
http://addacsystem.com/firmwares/ADDAC207_FIRMWARE.zip
It won't hurt to run it through another update again I suppose-- I'm selling my unit so it would be a good service since I already got the serial board.
well not 100% myself but I find it over sensitive and after the 30 sec (was it 30?) idle time it starts to fire off spasm triggers winch is a bit annoying only if I unplug the input will it stop (perhaps a better PSU could sort this? less ripple)meatbeatz wrote:In the first post on this thread it says:
Yet this post was last updated on:Here's the direct link to our Firmware Upgrade OSX App (vs: J9) - last update March 2nd, 2015:
How can that be? Am I going crazy? If not, I'm about to!!!!!Last edited by ADDAC System on Fri Oct 10, 2014 2:24 am; edited 2 times in total
So I download the J9 firmware via the above link, open in Mac OSX Finder to find that J9 firmware file was created was 6/8/2014.
There is no documentation for J9 but I have been told by Andre that all gate issues have been fixed with J9. Can somebody please set me straight?
Xloader said
30060 bytes uploaded
30060 bytes uploaded
Last edited by overjoid on Wed Jul 08, 2015 11:22 pm, edited 1 time in total.
Hello - I love my ADDAC case and these quantizers. I did the J9 update, but there is still an accidental gatemode switching that can occur after 60 seconds.
"This Gate in ON/OFF detection is made in software.
After the detection goes On, and if the user removes
the gate in jack it will automatically goes to Off after
60 seconds. If the user want to reset voices before the
60 seconds period Button 6 (Gate L) can be pressed at
the same time as the voice number button (1 to 4).
For example to Reset voice 2 Gate In, the user needs to
press button 2 and 6 at the same time.
This will resume the behavior without regarding the
Gate In until a new jack is plugged in."
____________________________________________________________________________________________________________
OK ---- So, the interval creation and gate detection are different things.
As of the current OS, the "CH234 slave to 1 setting" has only taken care of the accidental mode switching that happens when sending 0V CV to "in" 2, 3, or 4.
The "no-gate-in-patched"-detection is still on a 60 second timer, so "gate detection" issues have not been resolved for anyone who wants their input gates to be spaced wider than 60 seconds.
I did a simple test:
Medium slow LFO into CV "in" (set the speed so you can kind of see it moving up and down on the quantizers LEDs);
make a single trigger pulse happen into "gate in" (start a stopwatch now if you'd like);
This trigger switches the quantizer into triggered operation and stops the quantizing of every step of the lfo and holds the value from the triggered moment;
now wait. . . . . . . . . at 60 seconds the quantizer "goes crazy" (switches back to untriggered mode of operation) . . . .
it stops thinking that I have a cable plugged into "gate in", but the cable is still plugged in.
Doesn't work for slow music (you won't make it past the 15th bar at 60bpm); I think it's why random outputs are sometimes happening for some people; this situation can definitely interrupt any nice long drone note.
It would be very very helpful to have another "Trig.R." Menu item to declare "I will be using gates", or "auto detect" (which already works for "I won't be using gates").
please,
thank you,
all the very best,
Roy
From the manual (last updated July 2013):__ag wrote:Hello,
I read through the last comments and made a new update (J_6) to save the CH234 slave to 1 setting in overall memory, so now it should keep your pre-defined setting after startup.
So with that setting off channels 234 will never be listening to channel one, with this long intervals between gates will not be a problem.
all the very best
andre
"This Gate in ON/OFF detection is made in software.
After the detection goes On, and if the user removes
the gate in jack it will automatically goes to Off after
60 seconds. If the user want to reset voices before the
60 seconds period Button 6 (Gate L) can be pressed at
the same time as the voice number button (1 to 4).
For example to Reset voice 2 Gate In, the user needs to
press button 2 and 6 at the same time.
This will resume the behavior without regarding the
Gate In until a new jack is plugged in."
____________________________________________________________________________________________________________
OK ---- So, the interval creation and gate detection are different things.
As of the current OS, the "CH234 slave to 1 setting" has only taken care of the accidental mode switching that happens when sending 0V CV to "in" 2, 3, or 4.
The "no-gate-in-patched"-detection is still on a 60 second timer, so "gate detection" issues have not been resolved for anyone who wants their input gates to be spaced wider than 60 seconds.
I did a simple test:
Medium slow LFO into CV "in" (set the speed so you can kind of see it moving up and down on the quantizers LEDs);
make a single trigger pulse happen into "gate in" (start a stopwatch now if you'd like);
This trigger switches the quantizer into triggered operation and stops the quantizing of every step of the lfo and holds the value from the triggered moment;
now wait. . . . . . . . . at 60 seconds the quantizer "goes crazy" (switches back to untriggered mode of operation) . . . .
it stops thinking that I have a cable plugged into "gate in", but the cable is still plugged in.
Doesn't work for slow music (you won't make it past the 15th bar at 60bpm); I think it's why random outputs are sometimes happening for some people; this situation can definitely interrupt any nice long drone note.
It would be very very helpful to have another "Trig.R." Menu item to declare "I will be using gates", or "auto detect" (which already works for "I won't be using gates").
please,
thank you,
all the very best,
Roy
Hello all,
There's a new firmware update available!
Version: K_4
Firmware upgrade pdf guide:
http://www.addacsystem.com/sites/defaul ... e_Rev4.pdf
All download links can be found inside the pdf.
K_4 updates:
.Corrected issue with saving and loading presets.
All the very best
Andre
There's a new firmware update available!
Version: K_4
Firmware upgrade pdf guide:
http://www.addacsystem.com/sites/defaul ... e_Rev4.pdf
All download links can be found inside the pdf.
K_4 updates:
.Corrected issue with saving and loading presets.
All the very best
Andre
Last edited by __ag on Fri Jul 07, 2017 7:02 am, edited 1 time in total.
So, are any of the freshly delivered 207 modules already loaded with this newest (Feb, 2018) firmware ?__ag wrote:Hello all,
There's a new firmware update available!
Version: K_4
My recent purchase is serial # 371.
(from the ADDAC website as of 6/2018)....
and from the Ver. 05 pdf...Last update version: L_3, February, 12th, 2018
L_3 updates:
. Added the functionality to save in the presets the new Assign function introduced in update L2.
Note that there are 2 versions of the upgrade process one for Serial Numbers below #265 and a second
one for all quantizers above Serial Number #265
"We'll be living in all the oceans now."
(type of music I make.... drone atmospheres, deep late-night beats.)
(type of music I make.... drone atmospheres, deep late-night beats.)
- Brendanleespengler
- Common Wiggler
- Posts: 102
- Joined: Fri Oct 14, 2016 8:53 am
- Location: Memphis, TN
- Contact:
“So, are any of the freshly delivered 207 modules already loaded with this newest (Feb, 2018) firmware?”
Ditto the same from another interested wiggler in the US. The folks at ADDAC are great via email; really attentive and helpful with inquiries. But, ordering the 207 direct from Portugal is impractical and expensive, unfortunately. Especially when you’re diggin on the black paneled version.
Any restocks w US retailers?
Ditto the same from another interested wiggler in the US. The folks at ADDAC are great via email; really attentive and helpful with inquiries. But, ordering the 207 direct from Portugal is impractical and expensive, unfortunately. Especially when you’re diggin on the black paneled version.
Any restocks w US retailers?
Brendan Lee Spengler / Electronic Sound Research: The Electric Cowboy, Sinner Frenz, MacMillan & Spengler, Viva L'American Death Ray Music, Teledildonics5000, etc.
- Brendanleespengler
- Common Wiggler
- Posts: 102
- Joined: Fri Oct 14, 2016 8:53 am
- Location: Memphis, TN
- Contact:
[/quote]
So, are any of the freshly delivered 207 modules already loaded with this newest (Feb, 2018) firmware ?
[/quote]
Ditto the same from another interested wiggler in the US. The folks at ADDAC are great via email; really attentive and helpful with inquiries. But, ordering the 207 direct from Portugal is impractical and expensive, unfortunately. Especially when you’re diggin on the black paneled version.
Any restocks w US retailers?
So, are any of the freshly delivered 207 modules already loaded with this newest (Feb, 2018) firmware ?
[/quote]
Ditto the same from another interested wiggler in the US. The folks at ADDAC are great via email; really attentive and helpful with inquiries. But, ordering the 207 direct from Portugal is impractical and expensive, unfortunately. Especially when you’re diggin on the black paneled version.
Any restocks w US retailers?
Brendan Lee Spengler / Electronic Sound Research: The Electric Cowboy, Sinner Frenz, MacMillan & Spengler, Viva L'American Death Ray Music, Teledildonics5000, etc.
- Paranormal Patroler
- Super Deluxe Wiggler
- Posts: 11193
- Joined: Tue Aug 30, 2011 3:40 pm
- Location: the Terminal beach
Re: ADDAC207 - Firmware Upgrade Process: Issues / Questions
Trying to do a fresh firmware (module not behaving) from macOS 10.15.7.
ADDAC updater runs through without updating. See log below. Any thoughts?
+ ------------------------------------------------------- +
#### ### ### #### ####
# # # # # # # # #
#### # # # # #### #
# # # # # # # # #
# # ### ### # # ####
#### # # #### ##### #### ### ###
# # # # # # # # #
#### #### #### # ## # # #
# # # # # # # #
#### #### #### # #### # # #
+ ------------------------------------------------------- +
ADDAC207 Firmware Update
USB-Serial Device Found: /dev/tty.usbserial-3 /dev/tty.usbserial-AL03TFP4
+ ------------------------------------------------------- +
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 46: [/dev/tty.usbserial-3
/dev/tty.usbserial-AL03TFP4: No such file or directory
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 57: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
Proceeding...
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 64: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 80: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
Burning new Firmware!
(USB-Serial Board Leds should be blinking by now)
+ ------------------------------------------------------- +
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 97: avr/bin/avrdude: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 109: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 121: avr/bin/avrdude: Bad CPU type in executable
+ ------------------------------------------------------- +
All Done!
Happy Patching!
+ ----------------------------------- + ADDAC System.2018 +
ADDAC updater runs through without updating. See log below. Any thoughts?
+ ------------------------------------------------------- +
#### ### ### #### ####
# # # # # # # # #
#### # # # # #### #
# # # # # # # # #
# # ### ### # # ####
#### # # #### ##### #### ### ###
# # # # # # # # #
#### #### #### # ## # # #
# # # # # # # #
#### #### #### # #### # # #
+ ------------------------------------------------------- +
ADDAC207 Firmware Update
USB-Serial Device Found: /dev/tty.usbserial-3 /dev/tty.usbserial-AL03TFP4
+ ------------------------------------------------------- +
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 46: [/dev/tty.usbserial-3
/dev/tty.usbserial-AL03TFP4: No such file or directory
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 57: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
Proceeding...
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 64: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 80: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
Burning new Firmware!
(USB-Serial Board Leds should be blinking by now)
+ ------------------------------------------------------- +
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 97: avr/bin/avrdude: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 109: CocoaDialog.app/Contents/MacOS/CocoaDialog: Bad CPU type in executable
/private/var/folders/r2/4w4pylcn2nschk_v2hmsh15w0000gn/T/AppTranslocation/9EE00B24-C10D-456E-BD79-229441342DA0/d/ADDAC207 Firmware.app/Contents/Resources/script: line 121: avr/bin/avrdude: Bad CPU type in executable
+ ------------------------------------------------------- +
All Done!
Happy Patching!
+ ----------------------------------- + ADDAC System.2018 +
The thing is to put a motor in yourself - fz