ACE goes V1.1
- KVRAF
- 4197 posts since 23 May, 2004 from Bad Vilbel, Germany
BUMP for the little "ACE Module Anatomy" document, available here:
http://www.mediafire.com/file/pcp7qvdwf ... natomy.pdf
http://www.mediafire.com/file/pcp7qvdwf ... natomy.pdf
- KVRist
- 320 posts since 21 Mar, 2010 from Manchester UK
cool!
Studio One, OS X 10.0, M-Audio Oxygen 25 keyboard.
Old websites:
http://www.bitwigtutorials.net Free Bitwig Studio tutorials
http://www.macableton.com Free Ableton Live and Mac tutorials.
Old websites:
http://www.bitwigtutorials.net Free Bitwig Studio tutorials
http://www.macableton.com Free Ableton Live and Mac tutorials.
- KVRAF
- 1950 posts since 17 Jun, 2005
Hmm, something went screwy with the ACE 1.1 GUI here.
When I turn a knob, it reaches the maximum graphical position (about "five-o-clock") before the actual value is at its maximum. As I keep turning, the knob wraps visually back to the minimum graphical position (about "seven-o-clock"), and goes a good bit clockwise from there, before stopping at a place where the actual value being adjusted hits its maximum. The values themselves have a linear continuity, so it just seems like the bitmaps for the knob are being shifted in their array.
Anyone else seeing this, and how might I cure it? Although everything functions under the hood, this GUI glitch makes adjusting values rather brain-wrecking
Edit: this happens in both Live and Reaper, and definitely seems like a GUI glitch instead of (for example) an automation mishap. It's consistent, and the range of every knob is affected in the same way.
When I turn a knob, it reaches the maximum graphical position (about "five-o-clock") before the actual value is at its maximum. As I keep turning, the knob wraps visually back to the minimum graphical position (about "seven-o-clock"), and goes a good bit clockwise from there, before stopping at a place where the actual value being adjusted hits its maximum. The values themselves have a linear continuity, so it just seems like the bitmaps for the knob are being shifted in their array.
Anyone else seeing this, and how might I cure it? Although everything functions under the hood, this GUI glitch makes adjusting values rather brain-wrecking
Edit: this happens in both Live and Reaper, and definitely seems like a GUI glitch instead of (for example) an automation mishap. It's consistent, and the range of every knob is affected in the same way.
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
Eeeek. Sounds like your operating system sorts the image files of the knob animation somewhat differently.
I thought that we did resort them internally, but maybe that hasn't made it into the final release yet...
Will fix in next release too!
I thought that we did resort them internally, but maybe that hasn't made it into the final release yet...
Will fix in next release too!
- KVRAF
- 1950 posts since 17 Jun, 2005
Ok
, good to know you're on the case, thanks!
The strange thing about it is, I'm on regular Windows XP Pro SP3, and the png files seem to sort normally everywhere but inside ACE. (I mean, viewing them in the file manager, also viewing them in an image viewer and advancing from the first to the last, which I presume relies on the OS alphabetical sort order, all results in a progression from 0000 to 0100 like it should.)
I think ACE 1.0 had the same files? It worked normally on this same system.
The strange thing about it is, I'm on regular Windows XP Pro SP3, and the png files seem to sort normally everywhere but inside ACE. (I mean, viewing them in the file manager, also viewing them in an image viewer and advancing from the first to the last, which I presume relies on the OS alphabetical sort order, all results in a progression from 0000 to 0100 like it should.)
I think ACE 1.0 had the same files? It worked normally on this same system.
-
- KVRist
- 237 posts since 5 Feb, 2006 from Toronto
GUI issue on MAC Au - if you select MAKE FAVORITE on a sound in a 2 column list in patch browser view the star will always tag the sound in the LEFT column of whichever sound you selected
would love to see some kind of drag and drop capability across all U-HE instruments to sort sounds without having to go into the finder...
would love to see some kind of drag and drop capability across all U-HE instruments to sort sounds without having to go into the finder...
Urs wrote:Will fix in next release too!
_________________
O
S
X
12.5 -- > + -->
VENTURA 13
- KVRAF
- 1950 posts since 17 Jun, 2005
Urs: do you have a time estimate for the next ACE release, by the way? I'm not trying to rush you if you're in the middle of something
, I'd just like to know when to expect diving into ACE again (it's workable with the current GUI bug, but at the same time it's quite maddening in a slightly comical way, heh.)
- KVRist
- 320 posts since 21 Mar, 2010 from Manchester UK
I havent had much in the way of ACE bugs, just a couple. It screwed up the undo history in Live a couple of times, and occasionally it loads with a filter in the wrong position, but it's been pretty well behaved apart from that.
Studio One, OS X 10.0, M-Audio Oxygen 25 keyboard.
Old websites:
http://www.bitwigtutorials.net Free Bitwig Studio tutorials
http://www.macableton.com Free Ableton Live and Mac tutorials.
Old websites:
http://www.bitwigtutorials.net Free Bitwig Studio tutorials
http://www.macableton.com Free Ableton Live and Mac tutorials.
- KVRAF
- 4197 posts since 23 May, 2004 from Bad Vilbel, Germany
A few more ACE tutorials are up (#8 to #10)
for all other tutorials etc., start here:
for all other tutorials etc., start here:
-
- KVRist
- 49 posts since 5 Jan, 2004
Is this a bug?
According to the ACE Manual, "LFO 1 is used for pitch modulation by default i.e. vibrato for both oscillators, and the amount is controlled by the modulation wheel (MIDI CC#1)." and the diagram shows LFO 1 hardwired to pitch-modulate both VCOs 1 and 2.
However, this doesn't seem to work in ACE 1.1 (at least on the default initialize patch).
To reproduce:
1. Instantiate ACE 1.1
2. In LFO 1, turn m-wheel knob fully clockwise (100.00) and set level to 50 (or higher)
3. Move Mod Wheel on Keyboard
Expected result: LFO modulates VCO 1 (& 2) to produce vibrato
Actual result: No modulation
Interestingly, it DOES work if you cable a link between LFO 1 and the VCO inputs. It seems it's the default hard-wiring that may have a problem.
On the other hand, maybe I'm just missing something...
According to the ACE Manual, "LFO 1 is used for pitch modulation by default i.e. vibrato for both oscillators, and the amount is controlled by the modulation wheel (MIDI CC#1)." and the diagram shows LFO 1 hardwired to pitch-modulate both VCOs 1 and 2.
However, this doesn't seem to work in ACE 1.1 (at least on the default initialize patch).
To reproduce:
1. Instantiate ACE 1.1
2. In LFO 1, turn m-wheel knob fully clockwise (100.00) and set level to 50 (or higher)
3. Move Mod Wheel on Keyboard
Expected result: LFO modulates VCO 1 (& 2) to produce vibrato
Actual result: No modulation
Interestingly, it DOES work if you cable a link between LFO 1 and the VCO inputs. It seems it's the default hard-wiring that may have a problem.
On the other hand, maybe I'm just missing something...
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
It does work though... on fresh instance
- turn Vibrato fully up
- set LFO1 level to 0.00
- set m-wheel to +100
Now you can control the amount of Vibrato by ModWheel.
Unlike Zebra, ACE has additive LFO amplitude modulation. The ModWheel ads/subtracts to the actual LFO level regardless. It's different in Zebra where the modulation amount is first subtracted from the total LFO level.
- turn Vibrato fully up
- set LFO1 level to 0.00
- set m-wheel to +100
Now you can control the amount of Vibrato by ModWheel.
Unlike Zebra, ACE has additive LFO amplitude modulation. The ModWheel ads/subtracts to the actual LFO level regardless. It's different in Zebra where the modulation amount is first subtracted from the total LFO level.
-
- KVRist
- 49 posts since 5 Jan, 2004
Thanks Urs - that was indeed what I was missing! It's working fine and I now understand the logic!
It was actually the vibrato knob being on the VCO 2 module that confused me the most - I didn't realize it affected VCO 1 as well as VCO 2 (I was working only with VCO 1 to begin with). I hadn't grasped the additive thing either but that does make sense now thanks.
I hope you don't mind a little constructive criticism here: I realize that space can be at a premium with the GUI but it does strike me that the VCO 2 area may not be the most intuitive place to look in the first instance for a control that actually affects both VCOs. I guess it may be too late to change that (and of course you may not agree anyway) but perhaps at least the next revision of the manual could include a full explanation of this as you just described?
Thanks again.
It was actually the vibrato knob being on the VCO 2 module that confused me the most - I didn't realize it affected VCO 1 as well as VCO 2 (I was working only with VCO 1 to begin with). I hadn't grasped the additive thing either but that does make sense now thanks.
I hope you don't mind a little constructive criticism here: I realize that space can be at a premium with the GUI but it does strike me that the VCO 2 area may not be the most intuitive place to look in the first instance for a control that actually affects both VCOs. I guess it may be too late to change that (and of course you may not agree anyway) but perhaps at least the next revision of the manual could include a full explanation of this as you just described?
Thanks again.
- u-he
- Topic Starter
- 30247 posts since 8 Aug, 2002 from Berlin
I know... placing Vibrato in VCO2 was a bit of a mishap. I found however that it isn't all to bad "once you know it". In the end, many controls in the VCO2 section are affected by both oscillators (sync, crossmod...). Hence adding a control that affects both was a less painful decision than breaking the otherwise nicely symmetric layout. The Vibrato knob would have to be squeezed *between* the sections, and that would have created a hole between all pairs of modules.
I also think that little quircks like that add a little character to synths, like the Vibrato slider on the old Korgs that controls PWM rate. Or the transpose keys on late Viruses that act as power buttons (which took me embarrassingly long time till I found it in the manual)
I also think that little quircks like that add a little character to synths, like the Vibrato slider on the old Korgs that controls PWM rate. Or the transpose keys on late Viruses that act as power buttons (which took me embarrassingly long time till I found it in the manual)
-
- KVRist
- 49 posts since 5 Jan, 2004
Yes, I suppose that logically, the vibrato knob should appear alongside the other three knobs below (since all four of them concern both VCOs 1 and 2), but I can also appreciate that that would have broken the symmetry of your layout. It's enough to give me a headache just starting to think about it!
In any case, as you say, it is indeed fine once you know it. To that end it would be great if a clear explanation could be added in the manual describing exactly how the default routing of LFO 1 vibrato works (including the additive interaction between level and modwheel controls on the LFO 1 panel and the vibrato control on the VCO 2 panel). I think this would really help clear up any potential confusion in this area for newcomers.
Thanks again Urs. ACE is ACE!
In any case, as you say, it is indeed fine once you know it. To that end it would be great if a clear explanation could be added in the manual describing exactly how the default routing of LFO 1 vibrato works (including the additive interaction between level and modwheel controls on the LFO 1 panel and the vibrato control on the VCO 2 panel). I think this would really help clear up any potential confusion in this area for newcomers.
Thanks again Urs. ACE is ACE!
