View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004704 | ardour | bugs | public | 2012-02-09 02:35 | 2013-01-22 22:00 |
| Reporter | wicked_boy | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Target Version | 3.0 | ||||
| Summary | 0004704: svn 11469 slow or no response from BCF-2000 (generic mode) | ||||
| Description | When using the BCF2000 ardour seems to have a slow or non-existent response to the faders.. and also the Mute button (which throws the faders down to 0 very quickly) I tested the same features with an edirol PCR 300 and did not have the same issues (weird) I tested the device against 2.8.12 and found the response to be very snappy ruling out an issue with the device or midi configuration | ||||
| Tags | surfaces | ||||
|
|
retested again with PCR and did notice that with fast movements ardour would lose track of the controller so this doesn't appear lmiited to the BCF but is more pronounced |
|
|
btw - if it's of any use I am using kernel 3.0.14 with RT patches. |
|
|
Are you using the generic surfaces code? If so, could you try again with recent SVN and see if it's any better? |
|
|
generic surfaces code.. I will try this weekend. |
|
|
hi now testing on revision 11646. it's improved to the point of being usable .. but still happens |
|
|
i also use the bcf in generic mode, and fast movements cause ardour to lose tracking. the fader seems to enter catch mode (which would be useful for non-motorized faders, but not for the bcf), and i have to move the fader slowly over the current controller value for ardour to continue tracking. blind guess: either the update rate is too low or ardour's tolerance towards controller jumps is. |
|
|
Assuming that you have (at some stage) done a waf install of Ardour, can you chaps both check that /usr/local/share/ardour3/midi_maps/bcf2000.map contains a line like <DeviceInfo bank-size="8" motorised="yes"/> toward the top? the motorised="yes" part should turn off the `catch' behaviour. I think A3 may look in /usr/local/share for midi maps before looking in the source tree. |
|
|
where would the bcf map come into play? i never told ardour i had a bcf. all i did was enable /generic/ midi support, assign a few controllers manually, and enable midi feedback. is there a way to turn off catch behaviour for generic midi devices as well? (btw, yes i have the bcf map file, and yes, it contains the motorized="yes" attribute) |
|
|
The map would come into play if you'd double-clicked on the generic surface in prefs and selected it. I'll have to think about how to present the "motorized" option for manual assignment. |
|
|
Hi, I'd ust like to reiterate .. I have this problem with an Edirol PCR 300 as well. It performs the same behaviour and goes into catch mode .. I'm also not using a MIDI map for the BCF (Although learning how to use one might not be a bad idea) |
|
|
nettings: your problems should be fixed if you double-click the "Generic Surface" in the prefs and then enable the "motorised" check button (in current SVN). |
|
|
Hi CTH103 .. With the BCR I changed the prefs to motorised and this seems to have fixed the problem.. for the BCR.. I have to check for the edirol again.. |
|
|
cth103, sorry for not getting back to this earlier. yes, the "motorized" toggle fixes the problem for me. would it be possible to store this setting? i think it should be in the user's global settings, but per-session would be fine as well if that's easier. cheers, jörn |
|
|
so the PCR-300 which isn't motorised displays the same behaviour, if the fader is moved fast it goes into latch, unless it is in motorised mode ... weird eh!! |
|
|
this is likely irrelevant at this point after many changes to generic MIDI code and the new MIDI binding maps. confirmation would be useful, otherwise will mark resolved in 1 week. |
|
|
see notes. |
|
|
no, it's not. ardour will still easily lose track of the BCF's faders even during not-so-rapid movements, and then switch to catch mode. only the "motorized" flag makes it behave as expected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-09 02:35 | wicked_boy | New Issue | |
| 2012-02-09 02:43 | wicked_boy | Note Added: 0012769 | |
| 2012-02-09 20:21 | cth103 | cost | => 0.00 |
| 2012-02-09 20:21 | cth103 | Target Version | => 3.0 |
| 2012-02-10 03:44 | wicked_boy | Note Added: 0012774 | |
| 2012-03-05 12:40 | cth103 | Tag Attached: surfaces | |
| 2012-03-07 14:42 | cth103 | Note Added: 0012875 | |
| 2012-03-07 14:42 | cth103 | Status | new => feedback |
| 2012-03-08 02:16 | wicked_boy | Note Added: 0012879 | |
| 2012-03-12 03:50 | wicked_boy | Note Added: 0012899 | |
| 2012-03-18 01:30 | nettings | Note Added: 0012957 | |
| 2012-03-18 01:53 | cth103 | Note Added: 0012959 | |
| 2012-03-18 02:00 | nettings | Note Added: 0012960 | |
| 2012-03-18 02:01 | nettings | Note Edited: 0012960 | |
| 2012-03-18 02:40 | cth103 | Note Added: 0012961 | |
| 2012-03-19 01:23 | wicked_boy | Note Added: 0012969 | |
| 2012-03-19 01:35 | cth103 | Note Added: 0012970 | |
| 2012-04-02 06:11 | wicked_boy | Note Added: 0013064 | |
| 2012-04-02 10:39 | nettings | Note Added: 0013066 | |
| 2012-04-04 13:27 | wicked_boy | Note Added: 0013077 | |
| 2012-04-25 00:03 | cth103 | Status | feedback => acknowledged |
| 2012-11-12 21:44 | paul | Note Added: 0014219 | |
| 2012-12-19 22:23 | paul | Note Added: 0014379 | |
| 2012-12-19 22:23 | paul | Status | acknowledged => resolved |
| 2012-12-19 22:23 | paul | Resolution | open => fixed |
| 2012-12-19 22:23 | paul | Assigned To | => paul |
| 2013-01-22 21:59 | nettings | Note Added: 0014565 | |
| 2013-01-22 21:59 | nettings | Status | resolved => assigned |
| 2013-01-22 21:59 | nettings | Resolution | fixed => reopened |
| 2013-01-22 22:00 | nettings | Relationship added | related to 0005296 |
