Hello again, Be.
(BTW, I prefer to call them 'presets' because a 'mapping' implies a
one-to-one relationship which is not necessarily the case when JS is
involved. Call them what you like. :) )
On 11/22/2015 02:22 PM, Be wrote:
> Reviewers have been saying for years that the haphazard controller
Hello,
Yes it's matter of what we want. Do we want some controllers be first
class citizen (like we do now) or do we want to
take leap to next level. We could also ask for sponsor for the project
but again it's just what we want and is being someone
slave without real benefit what Mixxx needs.
Hi Tuukka,
this is not an easy question.
There will be a benefit for the manufacturer if we build a first class
mapping for one, but not for an other.
If we by a controller via the normal distribution chain, there are many
parties which earn money from that.
This feels like a bead deal compared t
Hello,
Should we have some fundraiser to buy some controllers for devs to make
good mappings for the high-end contollers?
Tuukka
23.11.2015, 00:22, Be kirjoitti:
> (I'm consoldiating these related threads into one.)
>
> On 11/19/2015 08:18 PM, RJ Ryan wrote:
>
> > The standards are much lower
Hi RAWRR, thanks for your input.
To be clear, I am not advocating for supporting newer controllers merely
for the sake of newness. I am advocating for that because controllers
have gotten better and cheaper over the years and people outside of the
bubble of current Mixxx users are more likely t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My two cents, Be:
I've been using Mixxx once a month or so every month for the last
five years, and was interested in it before then even. I love this
program and admire the developer community enormously.
I shop for controllers by form factor and fe
(I'm consoldiating these related threads into one.)
On 11/19/2015 08:18 PM, RJ Ryan wrote:
> The standards are much lower since there is little risk to doing so. If
> we took in C++ patches without review we could cause crashes or actual
> damage to the user's computer. The sandboxed environme
On 11/20/2015 10:53 AM, Sean M. Pappalardo - D.J. Pegasus wrote:
> On 11/19/2015 11:06 PM, Be wrote:
>> Also, what devices do people want supported? IMO it is a big problem
>> that Mixxx lacks much support for popular brands that make quality
>> hardware that is commercially available today. Wher
On 11/19/2015 11:06 PM, Be wrote:
> Also, what devices do people want supported? IMO it is a big problem
> that Mixxx lacks much support for popular brands that make quality
> hardware that is commercially available today. Where is the support
> for contemporary Native Instruments, Pioneer, Aka
This Docuwiki plugin looks helpful:
https://www.dokuwiki.org/plugin:discussion
On 11/16/2015 05:22 AM, Tuukka Pasanen wrote:
> Hello,
> GIT would be best solution but probably will fail the reason you
> mentioned.. should we use pages talk-version as new stuff incubator and
> then add it to main
On 11/19/2015 08:47 PM, RJ Ryan wrote:
> Hi Be,
>
> On Thu, Nov 19, 2015 at 6:16 PM, Be mailto:b...@gmx.com>>
> wrote:
>
> I'm concerned about having mapping developers not be involved in the
> development workflow. How can we expect mappings to be maintained
> and keep up with new fea
Hi Be,
On Thu, Nov 19, 2015 at 6:16 PM, Be wrote:
> I'm concerned about having mapping developers not be involved in the
> development workflow. How can we expect mappings to be maintained and keep
> up with new features in Mixxx if they aren't? Moreover, how can we expect
> them to be documente
I'm concerned about having mapping developers not be involved in the
development workflow. How can we expect mappings to be maintained and
keep up with new features in Mixxx if they aren't? Moreover, how can we
expect them to be documented? There are many undocumented mappings
included in Mixxx
Hi Be / Tuukka,
Sorry for missing this discussion. This is a great topic to have guidelines
around.
I'm concerned about expecting the preset contributor to be involved in our
development workflow (Git, GitHub). This is a high bar that's going to
exclude a large portion of our user base from parti
Hello,
GIT would be best solution but probably will fail the reason you
mentioned.. should we use pages talk-version as new stuff incubator and
then add it to main page?
Tuukka
13.11.2015, 09:06, Be kirjoitti:
> Interesting idea, but I'm concerned that requiring people to do more
> work to upd
Interesting idea, but I'm concerned that requiring people to do more
work to update the wiki would keep people away from contributing to the
wiki more.
On 11/13/2015 01:01 AM, Tuukka Pasanen wrote:
> Hello,
> Dokuwiki also have markdown support with plugin so should we have
> 'original' in githu
Hello,
Dokuwiki also have markdown support with plugin so should we have
'original' in github as rst-file (If we like translations also). Then we
could have these as base for Dokuwiki then use normal Pull Requests to
update those. Little bit double effort but as Be said more qualified
documenta
Thanks. I propose adopting this as our procedure for writing
documentation when the author is not very comfortable with English:
1. Original author writes documentation to the best of their ability
2. Original author posts on this mailing list or submits a pull request
asking for someone who kno
Hello,
Ok I updated Wiki someone with better understanding English should read
it (and correct it) and everyone else also because we have to maintain
these conventions.
Tuukka
12.11.2015, 15:17, Be kirjoitti:
>
>
> On 11/12/2015 12:32 AM, Tuukka Pasanen wrote:
>> Hello,
>> Sorry this is lacking
On 11/12/2015 12:32 AM, Tuukka Pasanen wrote:
> Hello,
> Sorry this is lacking time of time but we should update wiki with these
> tools I think:
> XML:
> libxml 'xmllint -format'
> or
> http://www.freeformatter.com/xml-formatter.html (with '2 spaces per
> indent level')
>
> Javascript:
> at
Hello,
Sorry this is lacking time of time but we should update wiki with these
tools I think:
XML:
libxml 'xmllint -format'
or
http://www.freeformatter.com/xml-formatter.html (with '2 spaces per
indent level')
Javascript:
at least header:
/
Seems like a good idea to require new scripts to use strict.
On 10/24/2015 10:06 AM, Tuukka Pasanen wrote:
> Hi,
> Can we expect them to use 'use strict'? In Perl that makes most of stupid
> coding conventions disappear. More on topic:
> http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more
That was already on Controller Mapping File Locations page, but now that
you mention it, I moved it to the Contributing Mappings page.
On 10/23/2015 12:29 AM, Tuukka Pasanen wrote:
> Hi,
> I'll try to come up with small template. Should we announce of naming
> scheme at wiki as it seems to be:
>
Hi,
I'll try to come up with small template. Should we announce of naming
scheme at wiki as it seems to be:
'Manucfacturer-Sellingname-Typenumber-scripts.js' and 'Manufacturer
Sellingname Typenumber-midi.xml'.
Tuukka
23.10.2015, 08:04, Be kirjoitti:
> No, there is not. It would be great if you
No, there is not. It would be great if you made these templates. We
could ship them with Mixxx and tell users on the wiki to look at those
templates.
On 10/22/2015 11:58 PM, Tuukka Pasanen wrote:
> Hello,
> Yes we have to express minumun requirements for javascript and XML. Is
> there possibilit
Hello,
Yes we have to express minumun requirements for javascript and XML. Is
there possibility have template js and XML with proper naming scheme or
is there anyt similiarities with these files. I have to investigate this
template thing.
Tuukka
23.10.2015, 06:56, Be kirjoitti:
> I started a s
I started a section on the Contributing Mappings wiki page
(http://mixxx.org/wiki/doku.php/contributing_mappings ) with guidelines
for designing mappings. If you would like to add to or change them,
discuss it here or edit the wiki.
--
27 matches
Mail list logo
