23 Dec
2010
23 Dec
'10
2:35 p.m.
Hello everybody,
We have a present for you, a new release of MusE.
The alpha indicates this is an early version so it's mainly
- a teaser to spread the word.
- an early adopters build.
- to welcome developers who want to port MusE to other platforms.
MusE has now been completely ported to the Qt4 architecture and we (mainly
Tim and Orcan)
are busy to make it even better than before, lots of gui stuff being
reworked.
MusE now also sports a new version of the DeicsOnze, DX11 emulating
softsynth, up from version 0.2 to 1.0.
The homepage has received a new look that we hope will give a better
indication of what MusE is and does.
Do visit http://muse-sequencer.org.
The full changelog is available at:
http://lmuse.svn.sourceforge.net/viewvc/lmuse/trunk/muse2/ChangeLog?revisio…
Find the download at:
https://sourceforge.net/projects/lmuse/files/
Happy Holidays!
The MusE Team
23 Dec
23 Dec
4:46 p.m.
Excerpts from Robert Jonsson's message of 2010-12-23 14:35:23 +0100:
Hello everybody,
We have a present for you, a new release of MusE.
The alpha indicates this is an early version so it's mainly
- a teaser to spread the word.
- an early adopters build.
- to welcome developers who want to port MusE to other platforms.
MusE has now been completely ported to the Qt4 architecture and we (mainly
Tim and Orcan)
are busy to make it even better than before, lots of gui stuff being
reworked.
MusE now also sports a new version of the DeicsOnze, DX11 emulating
softsynth, up from version 0.2 to 1.0.
The homepage has received a new look that we hope will give a better
indication of what MusE is and does.
Do visit http://muse-sequencer.org.
The full changelog is available at:
http://lmuse.svn.sourceforge.net/viewvc/lmuse/trunk/muse2/ChangeLog?revisio…
Find the download at:
https://sourceforge.net/projects/lmuse/files/
Happy Holidays!
The MusE Team
Hi there,
I tried building muse to give it a spin today, but the build failed:
Linking CXX shared library libmuse_core.so
[ 90%] Built target core
Scanning dependencies of target muse
[ 90%] Building CXX object muse/CMakeFiles/muse.dir/main.o
Linking CXX executable muse2
midiedit/libmuse_midiedit.so: undefined reference to
`CtrlEdit::CtrlEdit(QWidget*, MidiEditor*, int, bool, char const*)'
midiedit/libmuse_midiedit.so: undefined reference to
`CtrlEdit::setTool(int)'
midiedit/libmuse_midiedit.so: undefined reference to
`CtrlEdit::writeStatus(int, Xml&)'
midiedit/libmuse_midiedit.so: undefined reference to
`CtrlEdit::setCanvasWidth(int)'
midiedit/libmuse_midiedit.so: undefined reference to
`CtrlEdit::readStatus(Xml&)'
collect2: ld returned 1 exit status
make[2]: *** [muse/muse2] Error 1
make[1]: *** [muse/CMakeFiles/muse.dir/all] Error 2
make: *** [all] Error 2
Aborting...
Arch Linux x86_64, gcc 4.5.1, qt 4.7.1
Anyway, upfront a couple of questions/suggestions.
website:
- Part Import/Export <- what does this refer to?
- Several types of audio tracks
* Audio inputs
* Audio outputs
* Wave tracks <- those sound weird, I hope I don't need to
create separate tracks for everything
- the following link (found here:
http://muse-sequencer.org/index.php/Download) is more distracting than anything:
http://sourceforge.net/scm/?type=svn&group_id=93414
building:
you seem to have switched to cmake but half way it seems. The build
instructions are rather weird and unusual for cmake.
creating build, cd'ing there and invoking cmake .. is not how it's
usually done.
Usually you configure using 'ccmake .' when you build manually or
-DCMAKE_BLA (which you do use) for automatic building.
A DESTDIR is a good thing to have since often enough software
is build in a chroot and hence "make install" as root will fail if it
tries to install into the real /usr.
Well, I'm looking forward to using a hopefully improved muse :)
6:10 p.m.
Hello Philipp,
2010/12/23 Philipp Überbacher <hollunder(a)lavabit.com>
Hi there,
I tried building muse to give it a spin today, but the build failed:
Linking CXX shared library libmuse_core.so
midiedit/libmuse_midiedit.so: undefined reference to
make: *** [all] Error 2
Aborting...
Hmm, no idea why this happens for you. Perhaps Orcan has some idea?
Anyway, upfront a couple of questions/suggestions.
website:
- Part Import/Export <- what does this refer to?
Midi-parts are xml based and can be stored and retrieved from disk. This
gives the possibility to produce a library of parts. Creating a public
library of parts (mainly for drums) has been discussed.
- Several types of audio tracks
* Audio inputs
* Audio outputs
* Wave tracks <- those sound weird, I hope I don't need to
They are regular tracks where you can put/record wave-parts, if you tried
older versions of MusE this is nothing new.
create separate tracks for everything
- the following link (found here:
http://muse-sequencer.org/index.php/Download) is more distracting than
anything:
http://sourceforge.net/scm/?type=svn&group_id=93414
Too much information? It's the standard sourceforge page, though you may be
right, we should probably rework that in the wiki.
building:
you seem to have switched to cmake but half way it seems. The build
instructions are rather weird and unusual for cmake.
creating build, cd'ing there and invoking cmake .. is not how it's
usually done.
Usually you configure using 'ccmake .' when you build manually or
-DCMAKE_BLA (which you do use) for automatic building.
A DESTDIR is a good thing to have since often enough software
is build in a chroot and hence "make install" as root will fail if it
tries to install into the real /usr.
I'm not convinced there is a usual way. Though you are right we are
beginners with cmake and it can probably be improved.
ccmake is just a curses frontend is it not? You can try to convince me but
instinctively I think we should steer clear of gui tools for building.
Well, I'm looking forward to using a hopefully
improved muse :)
Thank you, we will try to improve the build and get it compiling on all
systems we can :)
Regards,
Robert
24 Dec
24 Dec
10:40 a.m.
Excerpts from Robert Jonsson's message of 2010-12-23 18:10:35 +0100:
Ok, never heard of it, and I'm not sure just 'part' is obvious.
Apparently I never got this far before. I found it quite confusing I
must say.
Worse though is that new input tracks are muted by default (took me a
while to figure out why I couldn't record anything despite proper
routing) and that you have to constantly re-arm everything (wav tracks
at least).
sf is horrible, a few lines on the wiki would be far better than this
horrible generic page.
Another thing I've noticed just now, apparently muse wrote a bunch of
wav and .wca files to the build directory (I might have run it from
there). I never told it to save anything and just using the cwd as a
dump isn't a good idea imho.
Anyway, I wish you good luck with muse and a nice holiday,
Philipp
Hello Philipp,
2010/12/23 Philipp Überbacher <hollunder(a)lavabit.com>
Thanks to someone on your channel muse builds after modifying
trunk/muse2/muse/midiedit/CMakeLists.txt to:
target_link_libraries (
midiedit
${QT_LIBRARIES}
al
icons
widgets
ctrl
)
ctrl needed to be added.
Hi there,
I tried building muse to give it a spin today, but the build failed:
Linking CXX shared library libmuse_core.so
midiedit/libmuse_midiedit.so: undefined reference to
make: *** [all] Error 2
Aborting...
Hmm, no idea why this happens for you. Perhaps Orcan has some idea? Anyway,
upfront a couple of questions/suggestions.
website:
- Part Import/Export <- what does this refer to?
Midi-parts are xml based and can be stored and retrieved from disk. This
gives the possibility to produce a library of parts. Creating a public
library of parts (mainly for drums) has been discussed. - Several
types of audio tracks
* Audio inputs
* Audio outputs
* Wave tracks <- those sound weird, I hope I don't need to
They are regular tracks where you can put/record wave-parts, if you tried
older versions of MusE this is nothing new. - the
following link (found here:
http://muse-sequencer.org/index.php/Download) is more distracting than
anything:
http://sourceforge.net/scm/?type=svn&group_id=93414
Too much information? It's the standard sourceforge page, though you may be
right, we should probably rework that in the wiki. building:
you seem to have switched to cmake but half way it seems. The build
instructions are rather weird and unusual for cmake.
creating build, cd'ing there and invoking cmake .. is not how it's
usually done.
Usually you configure using 'ccmake .' when you build manually or
-DCMAKE_BLA (which you do use) for automatic building.
A DESTDIR is a good thing to have since often enough software
is build in a chroot and hence "make install" as root will fail if it
tries to install into the real /usr.
I'm not convinced there is a usual way. Though you are right we are
beginners with cmake and it can probably be improved.
ccmake is just a curses frontend is it not? You can try to convince me but
instinctively I think we should steer clear of gui tools for building.
Well, I'm looking forward to using a
hopefully improved muse :)
Thank you, we will try to improve the build and get it compiling on all
systems we can :)
Regards,
Robert
10:46 p.m.
2010/12/24 Philipp Überbacher <hollunder(a)lavabit.com>
Cool, if it's not already added (guessing it is) I'll add it.
Ok, never heard of it, and I'm not sure just 'part' is obvious.
True, I'll fix the text.
Apparently I never got this far before. I found it quite confusing I
must say.
Worse though is that new input tracks are muted by default
That is a good point, I'll see if we can make it clearer.
Hmm, no idea
why this happens for you. Perhaps Orcan has some idea?
Thanks to someone on your channel muse builds after modifying
trunk/muse2/muse/midiedit/CMakeLists.txt to:
target_link_libraries (
midiedit
${QT_LIBRARIES}
al
icons
widgets
ctrl
)
ctrl needed to be added.
Anyway,
upfront a couple of questions/suggestions.
website:
- Part Import/Export <- what does this refer to?
Midi-parts are xml based and can be stored and retrieved from disk. This
gives the possibility to produce a library of parts. Creating a public
library of parts (mainly for drums) has been discussed. - Several types of audio tracks
* Audio inputs
* Audio outputs
* Wave tracks <- those sound weird, I hope I don't need to
They are regular tracks where you can put/record wave-parts, if you tried
older versions of MusE this is nothing new. (took me a
while to figure out why I couldn't record anything despite proper
routing) and that you have to constantly re-arm everything (wav tracks
at least).
If you just want to record one track the currently selected track is
rec-enabled when you click rec.
I guess there are different "schools" how this should be handled, it works
pretty good for me but I'm open for ideas for how to change it.
Another thing I've noticed just now, apparently
muse wrote a bunch of
wav and .wca files to the build directory (I might have run it from
there). I never told it to save anything and just using the cwd as a
dump isn't a good idea imho.
This is a very good point and a very weak area of MusE. Working with it a
long time you tend to do the extra mouseclicks (creating a directory and
storing the project in it and then hitting rec) without thinking.
Will look at it right away.
Regards,
Robert
27 Dec
27 Dec
3:15 p.m.
Excerpts from Robert Jonsson's message of 2010-12-24 22:46:13 +0100:
Ok, never heard of it, and I'm not sure just 'part' is obvious.
True, I'll fix the text.
Apparently I never got this far before. I found it quite confusing I
must say.
Worse though is that new input tracks are muted by default
That is a good point, I'll see if we can make it clearer.
I'll try to give you a close to real-world example why it's problematic
the way it currently is.
Imagine you want to record a drum set. There are different philosophies
for recording drums, but frequently a large number of mics is used. It's
problematic for anything that needs more than two channels, but just for
this explanation let's assume you want to record a drumkit using 10
mics.
What you need to do:
Create either 10 mono or 5 stereo input tracks.
Create 10 mono wave tracks.
Route the inputs to the wave tracks using a popup-menu on each track.
Unmute each input track.
Arm each of the ten wave tracks.
Click the big record button.
Click play.
Press stop.
-- you're recording your first take at this point, jack routing and
playback of any kind not included
-- to record your next take, all you have to do is
Arm each of the ten wave tracks.
Click the big record button.
Click play.
-- repeat until your fingers fall off
I hope it's clear that the current 'the selected track gets auto-armed'
behavior
is not a solution when you need to record more than a single track.
I firmly believe that the number of clicks required should be reduced as
much as possible. I'm sure Alex will tell you 'a bit' about keyboard
navigation, so I'll save myself this part of the sermon.
2010/12/24 Philipp Überbacher
<hollunder(a)lavabit.com>
Cool, if it's not already added (guessing it is) I'll add it.
It's not (yet).
Hmm, no
idea why this happens for you. Perhaps Orcan has some idea?
Thanks to someone on your channel muse builds after modifying
trunk/muse2/muse/midiedit/CMakeLists.txt to:
target_link_libraries (
midiedit
${QT_LIBRARIES}
al
icons
widgets
ctrl
)
ctrl needed to be added.
Anyway,
upfront a couple of questions/suggestions.
website:
- Part Import/Export <- what does this refer to?
Midi-parts are xml based and can be stored and retrieved from disk. This
gives the possibility to produce a library of parts. Creating a public
library of parts (mainly for drums) has been discussed. - Several types of audio tracks
* Audio inputs
* Audio outputs
* Wave tracks <- those sound weird, I hope I don't need to
They are regular tracks where you can put/record wave-parts, if you tried
older versions of MusE this is nothing new. (took me a
while to figure out why I couldn't record anything despite proper
routing) and that you have to constantly re-arm everything (wav tracks
at least).
If you just want to record one track the currently selected track is
rec-enabled when you click rec.
I guess there are different "schools" how this should be handled, it works
pretty good for me but I'm open for ideas for how to change it. Another thing
I've noticed just now, apparently muse wrote a bunch of
wav and .wca files to the build directory (I might have run it from
there). I never told it to save anything and just using the cwd as a
dump isn't a good idea imho.
This is a very good point and a very weak area of MusE. Working with it a
long time you tend to do the extra mouseclicks (creating a directory and
storing the project in it and then hitting rec) without thinking.
Will look at it right away.
Regards,
Robert
29 Dec
29 Dec
1:42 a.m.
On Thu, 23 Dec 2010 14:35:23 +0100, Robert Jonsson wrote:
Hi muse 2 builds fine here. However how do you tell it to install to
lib64 rather than lib (Slackware64-13, multilib). If using configure
scripts, autotools you would pass --libdir= to the configure script.
Am I missing something obvious or is this on a to do list somewhere ?
Thanks
3:40 a.m.
muse doesn't put anything in /lib - if you don't want to use /usr/local
as your default path then pass [-DCMAKE_INSTALL_PREFIX=/usr ]
after the cmake command.
hth
g.
On 12/29/2010 11:42 AM, mickski wrote:
On Thu, 23 Dec 2010 14:35:23 +0100, Robert Jonsson
wrote:
Hi muse 2 builds fine here. However how do you tell it to install to
lib64 rather than lib (Slackware64-13, multilib). If using configure
scripts, autotools you would pass --libdir= to the configure script.
Am I missing something obvious or is this on a to do list somewhere ?
Thanks
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5073
days inactive
5079
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Bernardo Barros -
Geoff Beasley -
mickski -
Philipp Überbacher -
Robert Jonsson