Sorry for the segfaults -- that was a general bug with the controller
branch which I already fixed in trunk but hadn't merged those fixes into
the branch. If you pull/update now you should get them.
On Sat, Apr 28, 2012 at 8:23 AM, zestoi <zes...@djism.com> wrote:
> just built features_point_and_click. a few issues, tho i am coming to this
> as a total noob - so please excuse any stupidness:
>
> * had to copy res/schema.xml to /usr/share/mixxx before it would run
>
Well, this branch didn't change anything but the trunk does have a new
schema.xml file. I generally run Mixxx like this:
./mixxx --resourcePath res/
Which uses the 'res' folder instead of /usr/share/mixxx.
> * connected my icon idj, went into enable the controller but the wizard
> button isn't clickable until i click OK and then open the dialog a 2nd time
> * didn't map any controls first time, closed mixxx
> * trying to run again it dumps:
>
> Debug [Controller]: Controller in script engine is: "iCON idj V1.01 MIDI
> 1"
> Debug [Controller]: Applying controller preset...
> Segmentation fault
>
>
> * .mixxx/controllers/iCON_idj_V1.01_MIDI_1.midi.xml existed but only
> contained the basic header/footer
> * deleting that file fixed the issue
> * ran again, mapped a bunch of controls this time, closed mixxx and core
> dumps at the same place even though the file is not empty
>
> * running via gdb the last few lines in the stacktrace are these:
>
> #0 ConfigObject<ConfigValue>::get (this=0x0, k=...) at
> src/configobject.cpp:155
> #1 0x080a91a4 in ConfigObject<ConfigValue>::getValueString (this=0x0,
> k=...) at src/configobject.cpp:203
> #2 0x080a9836 in ConfigObject<ConfigValue>::getConfigPath (this=0x0) at
> src/configobject.cpp:332
> #3 0x08169677 in Controller::applyPreset (this=0xa7bce720) at
> src/controllers/controller.cpp:80
>
>
> * deleted that file again and now when i try to run mixxx it tells me i
> don't have any sound devices configured - maybe it just can't open them now
> (as ALSA does show up as selected in the config window when i click
> "reconfigure") due to the crashes?
>
> * agree that the first and last pages in the wizard should be removed
>
Removed now
> * would be nicer instead of having the big list of mappable controls (or a
> hierarhical tree of controls) to have two pulldowns, one for group like
> "transport" and the other only containing the controls for that group
>
Done now.
> * displaying the first two midi bytes to say what control has been mapped
> is a bit geeky and meaningless to most people, should be easy to display
> something more like Ch1.CC010 or Ch2.NoteA#4 etc
>
> Good point -- I'll fix this post-merge.
> i like the point and click interface especially with the window staying on
> top of mixxx when you select new controls ;)
>
> On 28 April 2012 13:45, S.Brandt <s.bra...@mixxx.org> wrote:
>
>> * Not being able to resize the Midi Learning dialog is a hot topic in
>> Traktor land, we should make the Learning wizard window resizable from the
>> beginning :-)
>>
>
> a hot topic indeed... it may not need to be resizable in it's current form
> - but could well do if we expand on it's features
>
it's resizeable now
> On 28 April 2012 05:15, Philip Whelan <pwhe...@mixxx.org> wrote:
>
> If we want to use a modifier system like Traktor (which, I totally
>> disagree with, by the way) we could generate the necessary javascript
>> on the fly. If a user wanted to modify it directly we could output a
>> full MIDI mapping which is not directly importable back into the
>> modifiers system.
>>
>
> i'm not saying to create a system just like traktor but to at least
> provide the ability to set/query shift conditions in some way from the
> mapping window (wizard). being able to define named modifiers/variables
> would make much more sense than what traktor does. somehow the user would
> have to be able to re-edit the mapping via a gui later on - which is why i
> suggested some "interim" format over just outputting javascript directly.
> 99% of users are never going to want to tweak scripts themselves and 99% of
> what anyone needs can be done using shift conditions.
>
> being able to to assign or delete a hotcue from the one button is the most
> obvious use - using a shift button somewhere on the controller
>
> it would be a very bad idea tho to lock out a user from using the mapping
> window as soon as they make *any* custom tweaks to a script.
> setting/querying shifts could just be done in the xml of course and actual
> javascript code (if needed) be generated on the fly.
>
> at the moment the learning wizard doesn't let you view all current
> mappings and shifts of course - which would be needed for this to work.
>
>
In 1.10 and earlier you could see your mappings and edit them in a table.
We've removed it and it won't be there in 1.11. Hopefully we'll come back
with something much nicer that works for both MIDI and HID in 1.12.
> If we do create a system where we emulate this
>> feature by generating Javascript on the fly though we could get the
>> best of both worlds and also help smooth out the learning curve.
>>
>
> agreed, which is what i was proposing. it makes no real odds what the
> actual script format is that's running so long as we can auto-generate it.
> a script format ala vdj could easily be converted and would encourage far
> more people to put in some logic (via a mapping window again of course) but
> that's probably not worth the effort (?) if we can at least get shifts into
> a mapping window. then *if* people really want to do something outside the
> box they can use javascript (tho that coffeescript looks a lot more
> tempting than raw javascript)
>
> make 90% of what's needed as simple as possible but still allow the extra
> 10% to be done as well is what i meant before - not to make that extra 10%
> impossible. no way that mixxx *shouldn't* have the scripting option - just
> that most people won't use it.
>
>
>> Internally, the modifier system could simply call an Javascript API we
>> design. That way the code would also be intuitive to users graduating
>> from modifiers to scripting.
>>
>
> exactly :)
>
> as an aside... when any modifier changes value every control that depends
> on that modifier will need to be rechecked of course - not only when that
> particular midi data comes in - so that led values can be updated
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
