Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplex: multiple grid/column group layouts are broken #19

Closed
GoogleCodeExporter opened this issue Mar 17, 2015 · 7 comments
Closed

Duplex: multiple grid/column group layouts are broken #19

GoogleCodeExporter opened this issue Mar 17, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

Multiple grid/column group layouts are broken
(use Kraken's modified Ohm64 layout for testing)

What steps will reproduce the problem?
1. Loading a control-map with two (or more) contiguous "columns" attributes 

What is the expected output? What do you see instead?
Groups are not closed before the next one is encountered

Original issue reported on code.google.com by bjorn.ne...@gmail.com on 4 Jul 2010 at 12:25

@GoogleCodeExporter
Copy link
Author

Original comment by bjorn.ne...@gmail.com on 4 Jul 2010 at 3:50

  • Changed title: Duplex: multiple grid/column group layouts are broken

@GoogleCodeExporter
Copy link
Author

Got the same prob with the BRF. Can't make the page controls two separate 
groups. they always end up in the encoder grid group. See attachment for a 
layout that should work, but doesn't...

Original comment by mueller....@googlemail.com on 9 Jul 2010 at 10:51

Attachments:

@GoogleCodeExporter
Copy link
Author

The testing I've done so far seems to indicate that it becomes a problem once 
two sibling groups both have the column property specified. 
Somehow, the Display doesn't "step out" of the first group, when building the 
virtual control surface. Then, the controls are added to the wrong group and 
the whole layout becomes corrupted. 

Original comment by bjorn.ne...@gmail.com on 9 Jul 2010 at 12:04

@GoogleCodeExporter
Copy link
Author

Original comment by bjorn.ne...@gmail.com on 16 Aug 2010 at 10:13

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

The fix doesn't work for me here. I've exchanged the Display.lua with the one 
in the current release 0.84 and the lower 4 pads of each group still don't work.

Appended are the prepared mappings for the microKORG and KONTROL49, which 
should work.


Original comment by beatslau...@googlemail.com on 16 Aug 2010 at 5:22

Attachments:

@GoogleCodeExporter
Copy link
Author

beatslaughter: this needs another fix danoise is already working on. This issue 
only fixes the visual layout of the control maps. They do look fine now, also 
in your examples.  

Danoise: the automatic y pos setting from the groups column count will fix this 
issues, won't it? Problem in bs's example is that the solo/pan controls use a 
different column count than the level group sliders.

Original comment by mueller....@googlemail.com on 16 Aug 2010 at 7:57

@GoogleCodeExporter
Copy link
Author

Yes, the pending changes should fix the remaining issue as well. I have no 
problem running the mixer here (and I also rewrote the Effect app, so the 
device navigator no longer use a UISlider, which is not able to span multiple 
lines...) 

Original comment by bjorn.ne...@gmail.com on 17 Aug 2010 at 11:09

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant