I found my MinGW branch at https://github.com/mixxxcommunity/mixxx, in a branch
called ulatekh-mingw. I branched that into my own repo and brought it up to
date. The merge didn't go very smoothly, but I managed to fix all the problems
by hand. (Good thing I kept the last bzr version of the
Done...see https://github.com/mixxxdj/mixxx/pull/25
Thanks in advance for taking a look at it.
From: Max Linke max_li...@gmx.de
To: Steven Boswell II ulat...@yahoo.com
Cc: mixxx-devel mixxx-devel@lists.sourceforge.net
Sent: Sunday, June 23, 2013 2:34 PM
I see that my auto-DJ-crates branch has been moved to github, but it's owned by
daschuer.
I had held off moving my own branches to github; the chatter on the list seemed
to say let Owen do it.
Not a big deal -- I can fork daschuer's repo and issue my own pull request.
My question is...where did
Right now I'm rescanning my track collection on my laptop, and I expected it to
be a short operation, but it's taking forever. I'm guessing it's because I
moved a large part of my track collection to a different partition on my hard
drive, even though the path remained the same. The issue is
It's been moved out of the testing repos is now available for everyone from
RPMFusion.
W00t!
Steven Boswell
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design,
Please see https://code.launchpad.net/~ulatekh/mixxx/mingw -- we can now build
the MS Windows version of Mixxx (including the installer) from Fedora Core.
The necessary information to build the dependent packages is at
https://github.com/ulatekh/fedora-mingw-ardour -- I'm working to get these
I finally built Fedora RPMs for all of Mixxx's dependencies, got them to pass
rpmlint/mock/fedora-review, and even submitted a few
package-requests, so they might actually end up in Fedora's repos.
Until then, here's a github repo containing all the files you'll need to turn
Fedora Core's
I just noticed something... build/mixxx.py refers to CFLAGS in one place, and
everywhere else in the build system, it's called CCFLAGS.
That looks like an inconsistency that should be fixed.
Thoughts?
Steven Boswell
--
You may follow along at https://bugzilla.rpmfusion.org/show_bug.cgi?id=2801 .
Hopefully it'll be in the yum repos soon!
The build failed on x86_64; I don't have a 64-bit Linux to test on. (I could
install one, but not now...I'm leaving for a trip tomorrow.) Has anyone tried
to build Mixxx
If you do that, I'll be glad to put my cmake knowledge to good use by reviewing
your work.
From: Tuukka Pasanen pasanen.tuu...@gmail.com
To: mixxx-devel mixxx-devel@lists.sourceforge.net
Sent: Monday, May 20, 2013 10:49 PM
Subject: Re: [Mixxx-devel] Building
The mixxx.pro in the lp:~ulatekh/ mixxx/mingw branch has been brought up to
date, at least as much as I know how to; feel free to try it out.
FYI, I've built mingw-phonon, but am still struggling to rebuild mingw-qt so
that it'll use phonon. Once that's done, I can enable vinylcontrol and hid
Maybe you're trying to build the 64-bit version?
I haven't tried that myself yet.
Maybe add machine=i386 to your scons line?
From: James J Fagan jfag...@binghamton.edu
To: mixxx-devel@lists.sourceforge.net
Sent: Monday, May 20, 2013 6:31 PM
Subject: Re:
I'm fairly familiar with cmake. But switching to another build system is a lot
of work; we'd have to be really sure there are enough benefits.
Also...real life is threatening to intrude any day now :-)
Steven Boswell
From: Daniel Schürmann dasch...@mixxx.org
.
From: James J Fagan jfag...@binghamton.edu
To: Steven Boswell II ulat...@yahoo.com
Sent: Monday, May 20, 2013 6:58 PM
Subject: Re: [Mixxx-devel] Compiling mixxx on linux
Thanks for all the help, I got passed this issue but now when I run using
./mixxx I get
Main
After building an MS Windows installer for Mixxx using the standard
instructions, I decided to try getting it to work with MinGW running under
Linux.
The branch at lp:~ulatekh/mixxx/mingw is the result of my work so far.
The qmake version (i.e. build/qtcreator/mixxx.pro) is a bit clunky, but can
PLEASE, let's not go the route of the Chrome/Firefox model. I _hate_ that.
Major versions should be reserved for changes that are not
backwards-compatible, like they were originally intended.
And at the risk of angering our lead developer, I think Chrome did it first. ;-)
So is the source code release in http://downloads.mixxx.org/mixxx-1.11.0/
stable now?
The issue is that I'd like to get an updated mixxx package onto rpmfusion.org,
and want to know if I can refer to that source release in the .spec file, e.g.
Source0:
Now that the release is out the door and we all have some breathing room, can I
get some opinions on my pending changes and blueprints?
https://bugs.launchpad.net/mixxx/+bug/1051106 is a simple implementation of an
incremental/pausable library-scan, to allow the locked-database problem during
Since I've done a little ffmpeg programming in the past, I thought I'd take a
look at this.
Hopefully I'm doing my comparison right; inside of a checkout of Mixxx's trunk,
I did bzr update -r 3365, since that seems to be the last version that was
merged into the ffmpeg branch.
Assuming my
Wait...it's easier than that...instead of having to fetch a QTextCodec, I can
just call QString::fromUtf8().
New patch. :-)
Steven Boswell
From: Steven Boswell II ulat...@yahoo.com
To: mixxx-devel@lists.sourceforge.net mixxx-devel@lists.sourceforge.net
Sent
The build problem I just ran into was reported on the forums; see
http://www.mixxx.org/forums/viewtopic.php?f=3t=4382 .
Unfortunately, no one ever answered him.
The problem is that the source code being built from wasn't part of a Bazaar
checkout, and src/SConscript doesn't handle that
Has anyone seen this?
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2413
I don't own any computers with an ARM arch, so I can't help with this, but for
anyone that knows ARM arches, this sounds like an easy fix...
Steven Boswell
I hope this is a dumb question...removing Browse mode is only for the Mac App
Store version, right?
From: RJ Ryan russelljr...@gmail.com
To: Too Many DJs mixxx-devel@lists.sourceforge.net
Sent: Wednesday, May 8, 2013 11:14 AM
Subject: Re: [Mixxx-devel] 1.11.0
One more hopefully dumb question...there's a difference between the Mac build
and the Mac App Store build, right?
I'd hate for a user to start with the Mac App Store build, go through all the
trouble of getting an open-source Mac build, and find that there's no
difference...
Hello all! Some time ago, I proposed allowing crates to be a source of random
tracks for Auto-DJ.
I have filed a blueprint for it; you may see it at
https://blueprints.launchpad.net/mixxx/+spec/auto-dj-crates .
I've also created a branch for it, and uploaded a solid beta version of it. I
On Wednesday, May 1, 2013 at 11:42 AM, RJ Ryan wrote:
On Wed, May 1, 2013 at 2:15 PM, Daniel Schürmann wrote:
Yes, we should solve this issue and use the const values in any case.
This allows to rely on IDE features like display call tree.
I think we should stick with whatever makes the code
On Monday, April 29, 2013 at 9:46 PM, RJ Ryan wrote:
Some database operations do need transactional semantics for their
whole operation (i.e. if you were to stop it half-way and commit to
allow other readers/writers to process) -- for example shuffling a
playlist. In this case multiple writers
Correct me if I'm wrong, but wouldn't a functional non-blocking database
access implementation be a lot simpler than what's been discussed here?
The issue is that some database operations are interruptible, although it's
more efficient for them to not be done incrementally. Library-rescan, and
Please see https://bugs.launchpad.net/mixxx/+bug/1171235 -- my performance
improvement to playlist/crate import is bugged, and I submitted a patch for it.
If you've imported playlists/crates with that code, you just have to delete
them and re-import them, and your database will be error-free
Please see https://bugs.launchpad.net/mixxx/+bug/1171235 -- my
performance improvement to playlist/crate import is bugged, and I
submitted a patch for it.
Not the first time broken code has made it in right before a release :).
Granted, but I'm deeply unthrilled to be the cause of such a thing.
I just posted a patch that implements incremental-rescan and pausable
rescanning.
See https://bugs.launchpad.net/mixxx/1.11/+bug/1051106 for more details.
BTW, I have three other bug-fix patches posted, ready for comment and/or commit:
https://bugs.launchpad.net/mixxx/+bug/1171232
We need a bug report to track those changes. So please file one, assign it to
you and add your patch. The status should be In Progress
Sigh...formality :-)
@RJ: What is the state of the 1.11.0 branch. It is still open for
patches like this?
I sure hope it is...I'm still finding bugs :-)
Enclosed is a patch that vastly improves the performance of importing crates
when the tracks are already in the database.
I ran into this problem while trying to build crates for various sub-sets of
already-imported tracks.
All it does is detect when tracks referred to during a crate-import
I went ahead and implemented my idea for allowing crates to serve as sources of
random tracks for auto-DJ. Hopefully you'll all warm up to the idea, or maybe
I'll add an option to the scons line like autodjcrates=1 to allow people to
compile it out if they so choose.
Right now, I have a
The core database code is in src/library/dao.
From: Łukasz Olender luki...@gmail.com
To: mixxx-devel@lists.sourceforge.net
Sent: Saturday, April 13, 2013 8:08 AM
Subject: [Mixxx-devel] Non-Blocking Database Access
Hi all,
I’m interested in GSoC
From what I can tell digging around on the Net, LADSPA support in Mixxx
existed at one time, but is now broken.
I can't seem to find any info on how it's broken, or what it would take to fix
it. Does anyone know?
All I know so far is that adding ladspa=1 to the scons command line leads to
the
about which version of Mixxx you are talking?
I'm doing all of my work in the 1.11 release branch. I want a stable version
of Mixxx with some extra features that I've implemented, so working in 1.11
seemed like my best option.
1: without interaction
2: pressing fade now (Bad track playing or
Please attach the patch to bug #1090888 and assign the bug to yourselves or
mark it as duplicate and use bug #870128 instead.
OK, done. The patch is attached to bug #1090888. Could some with write
privileges on the bzr database commit this change push it into the 1.11.0
branch, please?
I'm not sure it adds much extra value to be able to select multiple crates as
your pool.
In my experience, it does -- that allows you to have several different sources
for the next random song. I commonly want to have several categories available.
Plus, we already have an Add to AutoDJ
on different
platforms, with different options and whatnot, but that would be pretty
unsettling. I'm running Mixxx on Fedora Core 17.
From: RJ Ryan russelljr...@gmail.com
To: Steven Boswell II ulat...@yahoo.com
Cc: mixxx-devel@lists.sourceforge.net mixxx-devel
I've been thinking over this feature and I'm not sure it's a direction we
should take.
If you can suggest an open-source jukebox app, I'll go work on that instead
and stop bothering you.
There are a bunch of great FLOSS jukebox apps out there --
Tomahawk and Banshee are two of my favorites and I
Here's my first idea for implementing djserver-like playlists in Mixxx.
I think the right metaphor is to allow crates to be added to auto-DJ. There
would be a sub-item under the Auto DJ tree-view item, called Crates.
There, you would see all the crates that have been loaded into auto-DJ. In
We should ensure that the Auto DJ has always n amount of tracks 4 in its
play list when connected to a crate so the user can foresee what will happen
Sure, the number of pending tracks to keep in auto-DJ, when there are crates
loaded into auto-DJ, can be configured.
How will this interact
The merge request from:
lp:~keithsalisbury/mixxx/track_selector_feature
looks really not nice without any comment.
Are you saying the feature is badly written and the source code isn't
documented? You lost me.
Re: crates in auto-DJ, let me tell you where I'm at so you can stop me if I'm
1) Flushing after every folder is scanned sounds like it could have a
significant impact on scanning performance. Using your friend's large
collection have you noticed any reduction in scanning speed?
I haven't rescanned the collection over again since making this change.
I can do that,
On Tuesday, April 9, 2013 at 10:45 PM, Daniel Schürmann wrote:
And thank you very much for your patch. I am impressed that you are
so familiar with the Mixxx code without any help!
The library-rescan code had a decent amount of source-code comments, so I
figured it out pretty quickly. I always
On Wednesday, April 10, 2013 at 2:01 PM, Daniel Schürmann wrote:
It would be wonderful if you can share your experience in real time
audio processing and play list generation with us and join us to make
Mixxx even better.
I'll do what I can! I guess I'll find out how much of my experience is
I was beating the heck out of auto-DJ last night, and got it to mess up a few
times. Sometimes, the played track wouldn't get removed from the list, and the
other deck would get loaded with the same track. I thought it was because of
shuffling the playlist, or adding new tracks to the top of
Hello all! I got a panicked call from a DJ/KJ friend of mine this weekend. He
knew I was handy with computers needed help DJing a gig he had that evening.
I quickly found mixxx (in the rpmfusion repo for Fedora Core 17), put it
through its paces, called him back to tell him I thought I
49 matches
Mail list logo
