huh.. im afraid this doesn't make sense.
hmm.. what i want to do, is merge several pulls into a branch.. and
keep master, and those pulls, up to date. I don't want to be
cherrypicking commits.
On Mon, Jul 10, 2017 at 5:48 PM, Daniel Schürmann wrote:
> Hi Waylon,
>
> I have not understand exactly
Hi Waylon,
I have not understand exactly how your state is, but it sounds like
git rebase -i
Is your friend.
It is best to have one branch per feature, splitted from an original master
commit.
So you schould branch your messed up branch again.
git checkout -b feature_a
Then rebase it, pickin
What is the proper way to update to master, for the pr's ive got
integrated into my source?
my source was created by first git checking out the master.. then i
pulled in ratings, git git pull with the pr number. Then i merged
master into it. I git pulled the WriteAudioTags pr, switched to it,
git m
Hi Harry,
We typically keep discussion about code on GitHub pull requests and use
the mailing list for broader discussions that don't specifically
reference code.
On 07/09/2017 01:59 PM, Harry van Haaren wrote:
Hi All,
The topic for this thread* is to discuss the current design of Ctlra
int
Just want chime in that mapping controllers in Mixxx by binding to Ctrla
callbacks and outputs directly in JS, without having to map midi signals in
XML beforehand would make for a great experience.
On Sun, Jul 9, 2017 at 11:35 AM, Harry van Haaren
wrote:
> On Sun, Jul 9, 2017 at 7:04 PM, Daniel
Hi Harry,
Ok, you are probably right.
I did not follow the early discussion, but I would agree to the Linux
Audio developers, that relying on those profiles will just not work.
A powerful mapping system is mandatory to fully support a specific
device from a specific application.
If we look a
Hi All,
The topic for this thread* is to discuss the current design of Ctlra
integration as per the PR on
github, and to discuss concrete next-steps to work towards a POC that
enables users to script
or map in some way the Ctlra events to the Mixxx ControlProxy objects.
The PR is here, and a yout
On Sun, Jul 9, 2017 at 7:04 PM, Daniel Schürmann wrote:
> Hi Harry,
>
> thank you for pointing me to ctlra_info_get_name.
> That is a good help to locate the event on the controller.
>
Yep, and together with the layout info, it is enough to provide good UX on
what it is, and where it is on the d
Hi Harry,
thank you for pointing me to ctlra_info_get_name.
That is a good help to locate the event on the controller.
However, I think we have the chance here to also represent the intended
use of a control in machine readable way and be also OSC compatible. For
example I have two gain buttons
On Sun, Jul 9, 2017 at 3:36 PM, Be wrote:
> I agree with Harry, assigning meaning to each event should be out of the
> scope of Ctlra. There is far too much variability between controllers for
> that to be useful, hence why no such system has been invented for MIDI DJ
> controllers and why device
I agree with Harry, assigning meaning to each event should be out of the
scope of Ctlra. There is far too much variability between controllers
for that to be useful, hence why no such system has been invented for
MIDI DJ controllers and why device-specific mappings exist.
One nice thing about
On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann wrote:
> Hi Harry,
>
> > At no point to I think Ctlra will *require* also using TCC. It just so
> happens that they complement each other well for my use-cases.
>
> That seams to be a good approach. If the architecture allows to put Ctlra
> drivers
Hi Harry,
> At no point to I think Ctlra will *require* also using TCC. It just
so happens that they complement each other well for my use-cases.
That seams to be a good approach. If the architecture allows to put
Ctlra drivers into runtime loaded object files, it does not matter which
compi
On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann
wrote:
> Hi Harry, Hi Be,
>
> here some comments:
>
> IMHO arguing about If C or JS is easier will not lead us ahead in this
> discussion.
>
Good point - apologies for the rat-hole.
> > As noted above, we can take TCC off the table for Mixxx's
Hi Harry, Hi Be,
here some comments:
IMHO arguing about If C or JS is easier will not lead us ahead in this
discussion. Both are easy and hard in different aspects. It is all an
issue about "Know your tools". The embedded developers in the
controller companies will be most likely C-Natives.
15 matches
Mail list logo
