Hi 魏欣
> I just got another idea that I can write a script to automatically insert
new data into current xml mapping preset files ...
That sounds good, but I am not sure if a script is such a great benefit,
because user interaction might be required. You can evaluate it later.
Thank you for your further explanations. It looks like your have a clear
view to your projects :-).
Kind regards,
Daniel
2013/7/9 魏欣 <weixind...@gmail.com>
>
> Hi Daniel,
> Thanks for your valuable suggestions.
>
> 2013/7/7 Daniel Schürmann <dasch...@mixxx.org>
>
>> Hi 魏欣,
>>
>> Cool, thank you for your explanations. Your ideas are very reasonable.
>>
>> > So I have an idea that I build another xml file which ..
>>
>> It's a question of responsibility. You have original proposed to extend
>> the xml file, right? I think that is reasonable because the mapping
>> developer will provide the picture and all other new data?
>>
>> Yes, You are right. I just got another idea that I can write a script to
> automatically insert new data into current xml mapping preset files. When
> next new version releases, we will do a patch for old users by running this
> script, and put forward new requirements for the future designers. What do
> you think?
>
>>
>> > Is it necessary to use C++?
>>
>> No, but according to the discussions on mixxx-devel thes mapping file
>> might be subject for change. In such case we have to change the C++ code in
>> Mixxx and the Python code in Backstage (which might be out of sight of the
>> Mixxx developer). These are the limitations by Backstage I have mention. It
>> would be really nice if we have a common place to edit the mapping. But
>> that is only one view. You should evaluate all pros and cons.
>>
> Ok, I see. I wll measure this any further. Currently, Python is more
> convenient for me to implement the basic functions, and I will make C++ a
> TODO solution,
>
>>
>>
> My personal long term favorite, is to move everything to js domain. We can
>> easily build the hash table from js so we have finally only one file to
>> maintain.
>>
> That sounds very cool!
>
>> > 1) pid.(uuid. this should stay the same with server side database)
>>
>> What is the use for this? To distinguish different mapping?
>> Currently we need to have a unique path (file name for each mapping) in
>> the res folder. What is the benefit of such additional identifier?
>>
>> I have noticed that our Mixxx uses a unique path as an identifier
> currentlly when I design my database, but I think it will lead a lot of
> potential porblems and there exists some limitations if I still use it as
> identifier for my forum portal development.
> 1) An identifer should be able to idetify a unique mapping both in local
> and cloud. A simple file path+name cann't meet the requirement. Because I
> cann't ensure that Mixxx on different computer use the same directory. The
> filename also may change for some stupid reason.
> 2) When we use path+name as an identifier, we can only keep one mixxx
> version and one schema version. Because we design that user can get new
> mapping through internet, and mixxx should recommend new version mapping
> according to mixxx version and schema version, so one mixxx versiona and
> one schema version for one mapping is not enough.
>
>> Have you thought about a Plug and Play Id for the mappings. Depending on
>> the controller interface, Mixxx can distinguish different hardware by
>> either USB Id or sysex messages. Maybe you should consider to track this
>> ID as
>> well.
>>
>> I don't think we should track Plug and Play Id. Because one mapping
> should support one kind of devices but not only one device. For one kind of
> devices, our preset name( manufacturer + controller name) is enough.
>
> Kind regards,
>>
>> Daniel
>>
>>
>
> --
> Best Regards!
> Xin Wei
>
>
>
>>
>>
>> 2013/7/7 魏欣 <weixind...@gmail.com>
>>
>>> Hi Daniel
>>> Thanks a lot!
>>>
>>> 2013/7/7 Daniel Schürmann <dasch...@mixxx.org>
>>>
>>>> Hi 魏欣
>>>>
>>>> Here some thought. But apologize if they are all rubbish, because I did
>>>> not follow your work that close.
>>>>
>>>> I am not sure if I get your point. It is correct that you are trying to
>>>> put the xml mapping file logical content in you database?
>>>>
>>> Yes, I am.
>>>
>>>> Is the mapping xml file generated from the database later?
>>>>
>>> If so, I am not in favor with this idea, because it will put additional
>>>> limitations to the Mixxx and Mapping development. It is possible to store
>>>> the mapping files as they are it is into the database?
>>>>
>>>> No, I just want to put the xml mapping file logical content in my
>>> database, but it is not enough. Another two items, <presets certification
>>> status> and <controller cover picture> is necessary for me to implement my
>>> search function I have designed. I know that it's better not
>>> put additional limitations to the Mixxx and Mapping development, So I have
>>> an idea that I build another xml file which store <preset name>(this is
>>> same as <name> in xml mapping file), <preset pid>, <cover picture>and
>>> <certification status>(these three items are necessary for me and going to
>>> add into my database. ) of all the preset in /res/controllers. This xml
>>> file will be parsed and the content will be pulled into my database at the
>>> same time with the xml mapping file logical content pulled into my
>>> database. How about this way? In fact I think this way is a bit
>>> wierd, <presets certification status> and <controller cover picture> shoud
>>> be same as <scriptfiles> stored in xml mapping file in logic.
>>>
>>>> If not, we Mixxx have a parser for the xml mappings. Did you have a
>>>> look at it? It stores the data from the xml in structures hand hash tables.
>>>> Maybe it is a good idea to split this part into a separate so/dll and add
>>>> your database code to it. This way we can maintain all midi mapping code at
>>>> one place.
>>>>
>>> I have readed the parser code. I have planed to make use of it to pull
>>> xml mapping file content into my database.
>>>
>>>> Is it possible to use C++ shared obejcts within the backstage server?
>>>>
>>>> I have written a parser script in Python within the backstage server.
>>> Is it necessary to use C++? This script file will be run only when we
>>> deploy our backstage server.
>>>
>>> Hope that helps!
>>>>
>>> Thanks again!
>>>
>>>
>>>> Kind regards,
>>>>
>>>> Daniel
>>>>
>>>>
>>>>
>>> Here I give a list of columns of preset table and file storage table in
>>> my planed client database.
>>> ====preset table ====
>>> 1) pid.(uuid. this should stay the same with server side database)
>>> 2) author.
>>> 3) url. Its values may be "null" for preset build by mixxx, "a forums
>>> link" for preset coming from mixxx forum, and "a wiki link" for preset
>>> coming from mixxx wiki.
>>> 4) description.
>>> 5) preset_source. If xml mapping preset file include <forums>, its value
>>> is "forums" and if include <wiki>, its value is "wiki", otherwise its value
>>> is "mixxx".
>>> 6) preset_status. Its values are "certificated","uncertificated", and
>>> "certificating".
>>> 7) mixxx_version
>>> 8) preset_name
>>> 9) controller_name
>>> 10) schema_version
>>> ==== file storage table====
>>> 1) fid(auto increment)
>>> 2) pid(Foreign key)
>>> 3) file type. its value are "xml","js","png"(show covers for search
>>> results)
>>> 4) file name
>>> 5) directory
>>>
>>> The contents in red are what I can not get from our current xml mapping
>>> preset file.
>>>
>>> Best Regards,
>>> weixin
>>>
>>>>
>>>>
>>>> 2013/7/6 魏欣 <weixind...@gmail.com>
>>>>
>>>>> Hi,
>>>>> I am working on providing interfaces for geting forum presets from
>>>>> server. Now I have deployed a server on my own computer ,built the
>>>>> database
>>>>> and been able to get database data from mixxx client through Tastypie API.
>>>>> But I find a problem that I have been ignored. It is how and where I can
>>>>> get presets data for filling server database.
>>>>> Now I have an idea that I can write a script parsing xml files in
>>>>> '/res/controllers/', and use these data to fill in server database tables.
>>>>> And for mixxx client, in order to support search from local and web
>>>>> server,
>>>>> we also should build tables at local database for presets. During
>>>>> initialization, Mixxx scans all the files in '/res/controllers/' and
>>>>> exports the presets info data into local database. The process that users
>>>>> search and download presets from web server is just to update local
>>>>> database. But I guess a problem is that exporting data from xml files may
>>>>> be incomplete, and some preset xml file maybe need some changes.
>>>>>
>>>>> Can you give me some suggestions?
>>>>>
>>>>> --
>>>>> Best Regards!
>>>>> Xin Wei
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Windows:
>>>>>
>>>>> Build for Windows Store.
>>>>>
>>>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>
>>
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
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
