This list is closed, nobody may subscribe to it.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(42) |
Dec
(99) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(29) |
Feb
(63) |
Mar
(46) |
Apr
(31) |
May
(58) |
Jun
(22) |
Jul
(112) |
Aug
(84) |
Sep
(67) |
Oct
(28) |
Nov
(93) |
Dec
(185) |
2005 |
Jan
(140) |
Feb
(99) |
Mar
(43) |
Apr
(118) |
May
(46) |
Jun
(73) |
Jul
(60) |
Aug
(25) |
Sep
(50) |
Oct
(41) |
Nov
(27) |
Dec
(60) |
2006 |
Jan
(46) |
Feb
(15) |
Mar
(122) |
Apr
(28) |
May
(26) |
Jun
(23) |
Jul
(28) |
Aug
(25) |
Sep
(3) |
Oct
(11) |
Nov
(26) |
Dec
(32) |
2007 |
Jan
(51) |
Feb
(18) |
Mar
(14) |
Apr
(7) |
May
(8) |
Jun
(8) |
Jul
(17) |
Aug
(17) |
Sep
(20) |
Oct
(1) |
Nov
(11) |
Dec
(40) |
2008 |
Jan
(18) |
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(15) |
Jun
(31) |
Jul
(5) |
Aug
(5) |
Sep
(16) |
Oct
(7) |
Nov
(9) |
Dec
(1) |
2009 |
Jan
(13) |
Feb
(12) |
Mar
(6) |
Apr
(6) |
May
(34) |
Jun
(88) |
Jul
(21) |
Aug
(1) |
Sep
(58) |
Oct
(138) |
Nov
(102) |
Dec
(76) |
2010 |
Jan
(58) |
Feb
(9) |
Mar
(6) |
Apr
(38) |
May
(59) |
Jun
(69) |
Jul
(24) |
Aug
(11) |
Sep
(33) |
Oct
(19) |
Nov
(13) |
Dec
(4) |
2011 |
Jan
(1) |
Feb
(32) |
Mar
(7) |
Apr
(13) |
May
(81) |
Jun
(24) |
Jul
|
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(11) |
Dec
|
2012 |
Jan
(27) |
Feb
(3) |
Mar
|
Apr
(16) |
May
(16) |
Jun
(5) |
Jul
(24) |
Aug
(1) |
Sep
(5) |
Oct
(32) |
Nov
(34) |
Dec
(48) |
2013 |
Jan
(46) |
Feb
(31) |
Mar
(14) |
Apr
(24) |
May
(19) |
Jun
(2) |
Jul
(13) |
Aug
(16) |
Sep
(22) |
Oct
(17) |
Nov
(19) |
Dec
(1) |
2014 |
Jan
(20) |
Feb
(6) |
Mar
(14) |
Apr
(13) |
May
(12) |
Jun
(11) |
Jul
(18) |
Aug
(14) |
Sep
(22) |
Oct
(7) |
Nov
(8) |
Dec
|
2015 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(11) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(5) |
2017 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(11) |
May
(4) |
Jun
(10) |
Jul
(28) |
Aug
(5) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(9) |
2018 |
Jan
(17) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Robert J. <spa...@gm...> - 2022-07-15 20:39:02
|
Hello anyone that might still be listening. Lately the only traffic on these lists has been spam. And I can't seem to find a way to get the spam emails off the list. So I thought it was about time to bite the bullet and close them down. For talking about MusE please use our forum: https://linuxmusicians.com/viewforum.php?f=61 Thanks, Robert |
From: Robert J. <spa...@gm...> - 2022-07-15 20:29:30
|
Hello anyone that might still be listening. Lately the only traffic on these lists has been spam. And I can't seem to find a way to get the spam emails off the list. So I thought it was about time to bite the bullet and close them down. For talking about MusE please use our forum: https://linuxmusicians.com/viewforum.php?f=61 Thanks, Robert |
From: Robert J. <spa...@gm...> - 2021-04-25 15:30:52
|
It is with great joy we present to you the final release of MusE 4.0. A great many things have been added and improved since the last stable release, nine months ago. To give a rather useless metric about the amount of work that has gone into MusE 4.0, our code repository has had more than 700 commits since the release of MusE 3.1.1! Here is an extremely condensed list of the most important changes since 3.1.1: * The core feature of 4.0 is the redesigned user interface with a huge amount of quality of life improvements. - Tabbed UI with Docks for common utility editors like Marker List, Mastertrack List and Event List. - All new dark theme with a lot of graphical improvements including lots of icons reworked in vector format. - Many new toolbars for quick access to common operations. - A lot of menu operations now list their related keyboard shortcut. - Many new keyboard shortcuts. * We now have an AppImage for easy installation on all distributions, both for releases and the bleeding edge development version. * Many many other fixes and improvements. For the complete list of changes see: https://github.com/muse-sequencer/muse/blob/4.0.0/src/ChangeLog The homepage: https://muse-sequencer.github.io/ Download: https://github.com/muse-sequencer/muse/releases/download/4.0.0/muse-4.0.tar.gz https://github.com/muse-sequencer/muse/releases/download/4.0.0/MusE-4.0.0-x86_64.AppImage Demos page: https://github.com/muse-sequencer/muse/wiki/Demos Forum: https://linuxmusicians.com/viewforum.php?f=61 |
From: Andrew C <cou...@gm...> - 2021-02-28 16:52:18
|
Hi Robert, My mistake! I'll take my question to their forums. Cheers, Andrew. On Sun, Feb 28, 2021 at 3:44 PM Robert Jonsson <spa...@gm...> wrote: > Hello Andrew, > > Sorry to say you are on the wrong mailing list, MusE and MuseScore are not > the same. > Not sure if there is a mailing list, try the forum > https://musescore.org/en/forum. > > Regards, > Robert > > > Den sön 28 feb. 2021 kl 16:40 skrev Andrew C <cou...@gm...>: > >> I should be more clear: >> >> The midi channel select feature (i.e staff text properties and select >> between arco/pizz/tremolo) seems to not work for any port number greater >> than 1. If I select port 2, channel 1 for an instrument, the arco plays, >> but staff text for switching to port 2, channel 2 or 3 for pizz and >> tremolo >> is completely ignored and Linuxsampler stays silent. Yet, I can switch to >> Port 2, Channel 2 in the mixer itself, and I hear a pizzicato sound, >> though >> this is still technically just the first channel it is selected as. >> >> Thanks, >> >> Andrew. >> >> On Sun, Feb 28, 2021 at 12:11 PM Andrew C <cou...@gm...> >> wrote: >> >> > Hi all, >> > >> > Having an issue with Musescore 3 and multiple midi out ports to an >> > external linuxsampler instance, namely that anything after port 2, >> channel >> > 1 is ignored and notes don't get sent. So I'm not sure how I can work >> with >> > several ports of 16 channels each in Musescore. >> > >> > Is this a bug? Are there any known workarounds? >> > >> > Thanks, >> > >> > Andrew. >> > >> >> _______________________________________________ >> Lmuse-user mailing list >> Lmu...@li... >> https://lists.sourceforge.net/lists/listinfo/lmuse-user >> > |
From: Robert J. <spa...@gm...> - 2021-02-28 15:44:32
|
Hello Andrew, Sorry to say you are on the wrong mailing list, MusE and MuseScore are not the same. Not sure if there is a mailing list, try the forum https://musescore.org/en/forum. Regards, Robert Den sön 28 feb. 2021 kl 16:40 skrev Andrew C <cou...@gm...>: > I should be more clear: > > The midi channel select feature (i.e staff text properties and select > between arco/pizz/tremolo) seems to not work for any port number greater > than 1. If I select port 2, channel 1 for an instrument, the arco plays, > but staff text for switching to port 2, channel 2 or 3 for pizz and tremolo > is completely ignored and Linuxsampler stays silent. Yet, I can switch to > Port 2, Channel 2 in the mixer itself, and I hear a pizzicato sound, though > this is still technically just the first channel it is selected as. > > Thanks, > > Andrew. > > On Sun, Feb 28, 2021 at 12:11 PM Andrew C <cou...@gm...> wrote: > > > Hi all, > > > > Having an issue with Musescore 3 and multiple midi out ports to an > > external linuxsampler instance, namely that anything after port 2, > channel > > 1 is ignored and notes don't get sent. So I'm not sure how I can work > with > > several ports of 16 channels each in Musescore. > > > > Is this a bug? Are there any known workarounds? > > > > Thanks, > > > > Andrew. > > > > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |
From: Andrew C <cou...@gm...> - 2021-02-28 12:45:20
|
I should be more clear: The midi channel select feature (i.e staff text properties and select between arco/pizz/tremolo) seems to not work for any port number greater than 1. If I select port 2, channel 1 for an instrument, the arco plays, but staff text for switching to port 2, channel 2 or 3 for pizz and tremolo is completely ignored and Linuxsampler stays silent. Yet, I can switch to Port 2, Channel 2 in the mixer itself, and I hear a pizzicato sound, though this is still technically just the first channel it is selected as. Thanks, Andrew. On Sun, Feb 28, 2021 at 12:11 PM Andrew C <cou...@gm...> wrote: > Hi all, > > Having an issue with Musescore 3 and multiple midi out ports to an > external linuxsampler instance, namely that anything after port 2, channel > 1 is ignored and notes don't get sent. So I'm not sure how I can work with > several ports of 16 channels each in Musescore. > > Is this a bug? Are there any known workarounds? > > Thanks, > > Andrew. > |
From: Andrew C <cou...@gm...> - 2021-02-28 12:11:30
|
Hi all, Having an issue with Musescore 3 and multiple midi out ports to an external linuxsampler instance, namely that anything after port 2, channel 1 is ignored and notes don't get sent. So I'm not sure how I can work with several ports of 16 channels each in Musescore. Is this a bug? Are there any known workarounds? Thanks, Andrew. |
From: Tim <te...@ro...> - 2019-06-07 08:16:37
|
On 6/5/19 6:36 AM, Andrew C wrote: > Hi all, > > What is libinstpatch used for and do I need it for reading/creating .idf > files or doing patch changes in Muse? No. libinstpatch (from the Swami project) allows you to use our fluidsynth MESS synth plugin to load a drum soundfont *.sf2 file and the drum note names will *automatically* appear in the Drum Editor, so that you don't have to manually enter these names or load a drum map file. It does help a lot. If I recall, I had trouble compiling libinstpatch recently. Also, the author informed me when I added it to MusE, that he has a replacement system that uses GIntrospection. I have not experimented with it yet, so libinstpatch will have to do for now. Reminder that we have a forum on linuxmusicians now. There has been far more activity there than here. Tim. > > Thanks, > > Andrew. > |
From: Andrew C <cou...@gm...> - 2019-06-05 09:37:14
|
Hi all, What is libinstpatch used for and do I need it for reading/creating .idf files or doing patch changes in Muse? Thanks, Andrew. |
From: Tim <te...@ro...> - 2019-01-08 23:49:51
|
Hello out there. Just a reminder for subscribers to these lists. Most of the juicy MusE discussions are now taking place in our forum at linuxmusicians.com There just seem to be a lot more eyeballs there and we're in good company. Lots going on. Join and subscribe to listen in and post. For issues we have the bug tracker at our github repository. Still here. Tim. |
From: Andrew C <cou...@gm...> - 2018-07-03 18:47:59
|
Hiya Tim, Thanks for this! Would it be possible to make the scroll wheel steps dynamically (i.e as an option in GUI behaviour)? 50 is working better than before. 60 might work better for me, but that's just personal taste. :-) Thanks! Andrew. On Sun, Jul 1, 2018 at 6:18 PM, Tim <te...@ro...> wrote: > On 07/01/2018 01:08 PM, Tim wrote: > >> On 06/30/2018 01:01 PM, Tim wrote: >> >>> >>> >>> On 06/30/2018 09:15 AM, Andrew C wrote: >>> >>>> Hey all, >>>> >>>> 2 questions. :) >>>> >>>> How do I "re-enable" the scrollwheel in Muse3? I'm using the latest >>>> Muse3 >>>> github source. >>>> >>>> Also, is it possible to increase the scrollwheel scroll resolution in >>>> Muse? >>>> I'm finding with my current setting that it's very slow and sluggish to >>>> try >>>> and scroll up/down 32-64 midi channels. >>>> >>>> Thanks, >>>> >>>> Andrew. >>>> >>> >>> Hi, thanks for reminding me. The scroll wheel somehow broke recently >>> in the Arranger. I'll take a look. >>> >>> The resolution is a fixed value but can be changed if we want. >>> IIRC Robert recently altered the resolution, I think? >>> >>> Perhaps we should add a user adjustable increment in the >>> Settings dialog. Maybe just a list of three or four convenient >>> values for the user. >>> >>> Or, we can simply add an 'accelerator' key such as Ctrl which will >>> temporarily increase the increment value by say 10 times. >>> >>> Tim. >>> >>> >> >> Hi, I pushed a fix in git master now. >> >> When Robert added touch pad support it ignored the mouse wheel. >> I have tried to respect what that code did, while fixing the >> mouse wheel. >> >> But, I do not have a touch pad to verify with! >> I must get one... >> >> Can someone verify that both mouse wheel and touch pad work >> satisfactory with this fix? >> >> Thanks. >> Tim. >> >> > Forgot to mention: About that accelerator key for faster scrolling: > After seeing the code, there doesn't seem to be many keys left > to use for accelerating. > > I was not aware that X allows the Alt key + mouse wheel > which changes it from vertical to /horizontal/ wheel values! > Works in any window. > > Thus the use of the Alt key seems out of the question. > Also, we use the Ctrl key for changing to zoom mode, > and the shift key for horizontal scroll mode. > > The only thing left maybe is to reclaim that shift key > somehow... > > So the only thing I could do ATM is increase the mouse > wheel scroll step size from 40 to 50. > Hope that helps. > > T. > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |
From: Tim <te...@ro...> - 2018-07-01 18:09:40
|
On 07/01/2018 01:08 PM, Tim wrote: > On 06/30/2018 01:01 PM, Tim wrote: >> >> >> On 06/30/2018 09:15 AM, Andrew C wrote: >>> Hey all, >>> >>> 2 questions. :) >>> >>> How do I "re-enable" the scrollwheel in Muse3? I'm using the latest >>> Muse3 >>> github source. >>> >>> Also, is it possible to increase the scrollwheel scroll resolution in >>> Muse? >>> I'm finding with my current setting that it's very slow and sluggish >>> to try >>> and scroll up/down 32-64 midi channels. >>> >>> Thanks, >>> >>> Andrew. >> >> Hi, thanks for reminding me. The scroll wheel somehow broke recently >> in the Arranger. I'll take a look. >> >> The resolution is a fixed value but can be changed if we want. >> IIRC Robert recently altered the resolution, I think? >> >> Perhaps we should add a user adjustable increment in the >> Settings dialog. Maybe just a list of three or four convenient >> values for the user. >> >> Or, we can simply add an 'accelerator' key such as Ctrl which will >> temporarily increase the increment value by say 10 times. >> >> Tim. >> > > > Hi, I pushed a fix in git master now. > > When Robert added touch pad support it ignored the mouse wheel. > I have tried to respect what that code did, while fixing the > mouse wheel. > > But, I do not have a touch pad to verify with! > I must get one... > > Can someone verify that both mouse wheel and touch pad work > satisfactory with this fix? > > Thanks. > Tim. > Forgot to mention: About that accelerator key for faster scrolling: After seeing the code, there doesn't seem to be many keys left to use for accelerating. I was not aware that X allows the Alt key + mouse wheel which changes it from vertical to /horizontal/ wheel values! Works in any window. Thus the use of the Alt key seems out of the question. Also, we use the Ctrl key for changing to zoom mode, and the shift key for horizontal scroll mode. The only thing left maybe is to reclaim that shift key somehow... So the only thing I could do ATM is increase the mouse wheel scroll step size from 40 to 50. Hope that helps. T. |
From: Tim <te...@ro...> - 2018-07-01 17:09:07
|
On 06/30/2018 01:01 PM, Tim wrote: > > > On 06/30/2018 09:15 AM, Andrew C wrote: >> Hey all, >> >> 2 questions. :) >> >> How do I "re-enable" the scrollwheel in Muse3? I'm using the latest Muse3 >> github source. >> >> Also, is it possible to increase the scrollwheel scroll resolution in >> Muse? >> I'm finding with my current setting that it's very slow and sluggish >> to try >> and scroll up/down 32-64 midi channels. >> >> Thanks, >> >> Andrew. > > Hi, thanks for reminding me. The scroll wheel somehow broke recently > in the Arranger. I'll take a look. > > The resolution is a fixed value but can be changed if we want. > IIRC Robert recently altered the resolution, I think? > > Perhaps we should add a user adjustable increment in the > Settings dialog. Maybe just a list of three or four convenient > values for the user. > > Or, we can simply add an 'accelerator' key such as Ctrl which will > temporarily increase the increment value by say 10 times. > > Tim. > Hi, I pushed a fix in git master now. When Robert added touch pad support it ignored the mouse wheel. I have tried to respect what that code did, while fixing the mouse wheel. But, I do not have a touch pad to verify with! I must get one... Can someone verify that both mouse wheel and touch pad work satisfactory with this fix? Thanks. Tim. |
From: Tim <te...@ro...> - 2018-06-30 17:01:47
|
On 06/30/2018 09:15 AM, Andrew C wrote: > Hey all, > > 2 questions. :) > > How do I "re-enable" the scrollwheel in Muse3? I'm using the latest Muse3 > github source. > > Also, is it possible to increase the scrollwheel scroll resolution in Muse? > I'm finding with my current setting that it's very slow and sluggish to try > and scroll up/down 32-64 midi channels. > > Thanks, > > Andrew. Hi, thanks for reminding me. The scroll wheel somehow broke recently in the Arranger. I'll take a look. The resolution is a fixed value but can be changed if we want. IIRC Robert recently altered the resolution, I think? Perhaps we should add a user adjustable increment in the Settings dialog. Maybe just a list of three or four convenient values for the user. Or, we can simply add an 'accelerator' key such as Ctrl which will temporarily increase the increment value by say 10 times. Tim. |
From: Andrew C <cou...@gm...> - 2018-06-30 13:15:45
|
Hey all, 2 questions. :) How do I "re-enable" the scrollwheel in Muse3? I'm using the latest Muse3 github source. Also, is it possible to increase the scrollwheel scroll resolution in Muse? I'm finding with my current setting that it's very slow and sluggish to try and scroll up/down 32-64 midi channels. Thanks, Andrew. |
From: Tim <te...@ro...> - 2018-02-22 02:44:05
|
- Restored dead precount feature. - It uses the 'slow-sync' feature of Jack Transport (and ours). - Moved our 'dummy' transport feature from Jack module into base class AudioDevice. This means ALL our drivers support it now. - It means ALL the drivers support precount. - Added README.metronome which explains a few things. Please read it! Thanks. Tim. PS I noticed a few bugs with undo-redo and with wave track pre-fetch 'retaining' audio even after a wave part has been deleted. Checking them out. |
From: Robert J. <spa...@gm...> - 2018-01-30 21:32:49
|
== MusE 3.0.2 release January 30, 2018 == This is another fix release, mainly improves MusE for packagers. - Major rework of internal muse plugins to remove core dependencies, which makes it possible to provide static builds with --no-undefined - Adde appdata file * Added ability to not support a default out, instead midi tracks will be assigned to the last created midi device or soft synth. (also just fixed a crash bug from the initial implementation For the complete list of changes see: https://github.com/muse-sequencer/muse/blob/muse_3_0_2/muse3/ChangeLog News section: http://muse-sequencer.org/index.php/News Download: http://muse-sequencer.org/index.php/Download Demos page: http://muse-sequencer.org/index.php/Demos Forum is dead - long live the NEW FORUM: https://linuxmusicians.com/viewforum.php?f=61 Keep on Rocking! The MusE Team |
From: Tim <te...@ro...> - 2018-01-28 23:42:01
|
Note: Be sure to start fresh by wiping the build folder and/or cleaning and pruning etc. CMake gives headaches if that is not done. On 01/28/2018 06:36 PM, Tim wrote: > Hi there. Sorry for the delay. This was a tedious fix. > I have pushed fixes to the git master. > See the ChangeLog for full details. > > It should now fully build with the two flags -no-undefined and > -DMODULES_BUILD_STATIC. > > Tested OK. Also tested normal regular build successfully > (without those flags). > > Can you test? I'll defer to Robert to roll up a release later to make > life easier for packagers. > > Thanks. > Tim. |
From: Tim <te...@ro...> - 2018-01-28 23:36:39
|
Hi there. Sorry for the delay. This was a tedious fix. I have pushed fixes to the git master. See the ChangeLog for full details. It should now fully build with the two flags -no-undefined and -DMODULES_BUILD_STATIC. Tested OK. Also tested normal regular build successfully (without those flags). Can you test? I'll defer to Robert to roll up a release later to make life easier for packagers. Thanks. Tim. |
From: Tim <te...@ro...> - 2018-01-19 03:49:03
|
Hi I'm cleaning up the MESS synth plugins so they don't depend on the main application core and so on. This is so the -no-undefined and MODULES_BUILD_STATIC linker flags can be used. I'm making good progress. MusE and its MESS synths will link independently. It's sooo much cleaner now! Much has been fixed. No commits yet, hang in there. The Simpledrums MESS synth has built-in support for using LADSPA plugins right there in the synth. It uses its own simple plugin support code, not the plugin support code from the main application, which is /way/ more complicated and dependent on stuff. Meanwhile, the Deicsonze synth /also/ supports plugins. But it uses the plugin system from the main application! That system is complicated bringing in LV2, DSSI, OSC, etc. etc. So it is very hard to extract that plugin system so that it can be a separate library which the MESS plugins can use. Ugly. And my fault. I did what I had to, to make it work. So I have made a simplified version of plugin support which can be used in both Deicsonze and Simpledrums, or any MESS synth. But we will *lose* the ability to use LV2, DSSI and VST plugins *within* Deicsonze. My question: Does anyone care about that? Is anyone actually using an LV2 plugin from within Deicsonze? Please tell me that you're not, he he ;-) Can you make do with using simpler LADSPA plugins? Or use the track's rack for all 'o them fancy plugins. Remember it's only MESS, and only Deicsonze affected. Benefit is any MESS synth can use this simple plugin system, The best solution would be to make changes to our plugin, LADSPA, LV2, DSSI, and VST host support code, and split them into linkable modules and so on. People could build new MESS synths. Other hosts could support MESS. (How likely is that, eh?) But all that would be verrry complicated. Tim. |
From: Robert J. <spa...@gm...> - 2018-01-16 10:04:09
|
== MusE 3.0.1 release January 16, 2018 == This is a hot fix release with some nagging bugs corrected. - Build fix for packagers building with --no-undefined - Looping did not play back the first event - Midi sustain wasn't handled correctly - Mute/Unmute/Off/On wave tracks caused them to lose playback sync + Note names are now displayed on the events in the pianoroll For the complete list of changes see: https://github.com/muse-sequencer/muse/blob/muse_3_0_1/muse3/ChangeLog News section: http://muse-sequencer.org/index.php/News Download: http://muse-sequencer.org/index.php/Download Demos page: http://muse-sequencer.org/index.php/Demos Forum is dead - long live the NEW FORUM: https://linuxmusicians.com/viewforum.php?f=61 Keep on Rocking! The MusE Team |
From: Tim <te...@ro...> - 2018-01-14 16:35:23
|
On 01/14/2018 04:56 AM, Robert Jonsson wrote: > > > 2018-01-14 9:54 GMT+01:00 Sebastian <se...@se... > <mailto:se...@se...>>: > > On 01/14/2018 12:01 AM, Tim wrote: > > Hi, please add this to your cmake build options: > > > > -DMODULES_BUILD_STATIC=TRUE > > > > Long ago MusE was built statically, monolithic style. > > Static builds are a no-go for packages. > > > I don't think we are talking about static with all dependencies built > in, just MusEs own code. But hopefully Orcan can report if he has > successfully built a package this time around. Sorry yes, I used poor phrasing of words. Not monolithic. Static in terms of our internal libraries. Building MusE with --no-undefined requires our DMODULES_BUILD_STATIC flag. MusE normally builds shared modules which all depend on each other. --no-undefined doesn't jive with that concept. It is asking for hard dependency links when they haven't even been built yet. IIUC --allow-shlib-undefined is the default and the reasons given are exactly the reasons why MusE needs it. It seems --as-needed may not produce the same results. One submitted terminal output showed it mistook fluidsynth's event.h for our event.h I can only assume that was the reason, because there's no trouble building MusE from source with default flags. So... Packager's choice then: 'Normal' build, or if you want --no-undefined then you need DMODULES_BUILD_STATIC. However, I am seeing issues with our DMODULES_BUILD_STATIC. As I mentioned, there are a few dependencies of Arranger on the core. I can straighten that out easily. What is /not/ so easy to straighten out are our MESS plugins. Our MESS plugins always build as shared libraries (they are plugins like any other plugin system.) If you give --no-undefined and DMODULES_BUILD_STATIC, the main app will build OK (given my pending fix of Arranger dependencies) but the MESS plugins have several dependencies on the core module. It is a bit of a... mess if you'll excuse the pun. The plugins were supposed be independent and stand-alone. But currently they need the core and a couple of other modules. So I'll try to straighten that out so that --no-undefined can be used if desired. Tim. > > Regards, > Robert > > > Sebastian > > -- > python programming - mail server - photo - video - https://sebix.at > cryptographic key at https://sebix.at/DC9B463B.asc and on public > keyservers > > > |
From: Robert J. <spa...@gm...> - 2018-01-14 09:56:22
|
2018-01-14 9:54 GMT+01:00 Sebastian <se...@se...>: > On 01/14/2018 12:01 AM, Tim wrote: > > Hi, please add this to your cmake build options: > > > > -DMODULES_BUILD_STATIC=TRUE > > > > Long ago MusE was built statically, monolithic style. > > Static builds are a no-go for packages. > I don't think we are talking about static with all dependencies built in, just MusEs own code. But hopefully Orcan can report if he has successfully built a package this time around. Regards, Robert > > Sebastian > > -- > python programming - mail server - photo - video - https://sebix.at > cryptographic key at https://sebix.at/DC9B463B.asc and on public > keyservers > > > |
From: Tim <te...@ro...> - 2018-01-13 23:01:52
|
Hi, please add this to your cmake build options: -DMODULES_BUILD_STATIC=TRUE Long ago MusE was built statically, monolithic style. But now, by default it is built modular style, each cpp/h is built as a module and the whole thing dynamically linked. Many of the modules depend on each other. Orcan may chime in here. I think he still may package MusE for Fedora RPM. He added the modular build and static option. *** Caveat: NOTE There are still some linker errors at the end: ----------------------------------------------- ... [ 89%] Building CXX object muse/CMakeFiles/core.dir/structure.o [ 89%] Building CXX object muse/CMakeFiles/core.dir/sync.o [ 89%] Building CXX object muse/CMakeFiles/core.dir/synth.o [ 89%] Building CXX object muse/CMakeFiles/core.dir/tempo.o [ 89%] Building CXX object muse/CMakeFiles/core.dir/thread.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/ticksynth.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/track.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/transport.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/undo.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/value.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/vst.o [ 90%] Building CXX object muse/CMakeFiles/core.dir/vst_native.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/wave.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/waveevent.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/wavetrack.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/xml.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/steprec.o [ 91%] Building CXX object muse/CMakeFiles/core.dir/wavepreview.o [ 91%] Linking CXX static library libmuse_core.a [ 91%] Built target core Scanning dependencies of target muse [ 92%] Building CXX object muse/CMakeFiles/muse.dir/main.o [ 92%] Linking CXX executable muse3 arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalCut()': arrangerview.cpp:(.text+0x1943): undefined reference to `MusECore::globalCut(bool)' arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalInsert()': arrangerview.cpp:(.text+0x1953): undefined reference to `MusECore::globalInsert(bool)' arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalSplit()': arrangerview.cpp:(.text+0x1963): undefined reference to `MusECore::globalSplit(bool)' arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalCutSel()': arrangerview.cpp:(.text+0x1976): undefined reference to `MusECore::globalCut(bool)' arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalInsertSel()': arrangerview.cpp:(.text+0x1986): undefined reference to `MusECore::globalInsert(bool)' arranger/libmuse_arranger.a(arrangerview.o): In function `MusEGui::ArrangerView::globalSplitSel()': arrangerview.cpp:(.text+0x1996): undefined reference to `MusECore::globalSplit(bool)' arranger/libmuse_arranger.a(pcanvas.o): In function `MusEGui::PartCanvas::paste(bool, MusEGui::PartCanvas::paste_mode_t, bool, int, int)': pcanvas.cpp:(.text+0xe9ba): undefined reference to `MusECore::movePartsTotheRight(unsigned int, int, bool, std::set<MusECore::Track*, std::less<MusECore::Track*>, std::allocator<MusECore::Track*> >*)' pcanvas.cpp:(.text+0xee17): undefined reference to `MusECore::movePartsTotheRight(unsigned int, int, bool, std::set<MusECore::Track*, std::less<MusECore::Track*>, std::allocator<MusECore::Track*> >*)' arranger/libmuse_arranger.a(pcanvas.o): In function `MusEGui::PartCanvas::cmd(int)': pcanvas.cpp:(.text+0xf2a3): undefined reference to `MusECore::movePartsTotheRight(unsigned int, int, bool, std::set<MusECore::Track*, std::less<MusECore::Track*>, std::allocator<MusECore::Track*> >*)' collect2: error: ld returned 1 exit status make[2]: *** [muse/CMakeFiles/muse.dir/build.make:145: muse/muse3] Error 1 make[1]: *** [CMakeFiles/Makefile2:461: muse/CMakeFiles/muse.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 ----------------------------------------------- I hope that those are the /only/ remaining errors and not just the beginning of many more. Big clue: All of those undefined functions are found in structure.cpp and declared in structure.h I examined all of the CmakeLists.txt files involved, but didn't see any trouble. I tried adding 'extern' to each of the declarations in structure.h, but same errors. Hmm... Checking. Anyone else see anything? Thanks. Tim. On 01/13/2018 04:58 PM, Tim wrote: > OK just built DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined. > Observed the errors! > > Hm, this is strange. The first error is this: > > CMakeFiles/al.dir/sig.o: In function `AL::SigList::ticks_beat(int) const': > sig.cpp:(.text+0xc3): undefined reference to `MusEGlobal::config' > C > > There's no problem with the sig module per se, it is just > simply referencing the config variable. > > But the config variable is defined in another module, in gconfig.cpp > > In gconfig.h it is declared as: > extern GlobalConfigValues config; > > So... what are we supposed to do? > > Hm. Checking... > > Tim. > > On 01/13/2018 03:57 PM, Tim wrote: >> OK we just got /another/ report of this in the issue tracker, >> someone packaging for Mandriva. >> >> Hm. So IIUC this problem may be because of my (our?) habit, >> perhaps incorrect, of forward referencing a lot of stuff >> in header files, so that I don't have to bring in a lot of other >> headers in that header file, so that changing one small thing >> in some small header somewhere doesn't cause a big recompilation. >> >> For example look at song.h, there are a lot of forward references. >> >> I had always assumed this was OK, since the symbols are eventually >> found within the .cpp file. >> >> Ironically though, I was thinking heavily about the consequences >> the other day - wondering if this habit might cause problems. >> >> And here we are. >> >> Does all this sound correct? >> >> If so, then we have a *lot* of changing to do. >> >> Or should we? Should the packagers do as the issue tracker >> poster suggested he /could/ do and remove that strict >> -no-undefined? He said this: >> >> "Since all the involved references are internal to the muse sources. >> this means that muse is actually rather underlinked. I can workaround >> the issue by forcing our build system to pass only "-Wl,--as-needed" >> >> "Perhaps this situation is safe, because all the needed symbols are >> provided by other muse internal modules and consequently they are >> always present, ruling out the chance of any runtime error; but I >> would argue that it is better to have a properly linked program, if >> this is doable..." >> >> >> Tim. >> >> >> On 01/13/2018 02:20 PM, Sebastian wrote: >>> On 01/13/2018 05:35 PM, Robert Jonsson wrote: >>>> Thanks for packaging MusE. >>>> First, if possible, add rtaudio as a dependency as it will allow >>>> running MusE with other backends than Jack. >>> I can't as rtaudio is not available in official openSUSE repositories >>> (I guess because of license issues, it's only in a third-party repo) >>>> As for the error I'm not sure what is going on, MusEGlobal::config >>>> seems defined to me.. >>>> I see this is happening while you try to create the package, does it >>>> occur already when running ./compile_muse.sh ? >>>> >>>> Tim, you run openSUSE, right? Seen anything similar? >>> This is not an openSUSE issue. The problem occurs during linking (not >>> /compiling/). I'm not a C/C++ programmer but AFAI found out, the >>> /--no-undefined/ during linking makes the linking process more >>> strict. Without that flag, compilation works because the undefined >>> references are /ignored/. Which does not mean that they exist, they >>> reference may work after later linking steps but how that works is >>> beyond my knowledge. As this flag is used for all packages in >>> openSUSE that use cmake, I guess that muse >>> Try building muse with the cmake parameter >>> DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined and you should get the >>> same errors. >>> >>> Sebastian >>> >>> P.S.: I don't see an issue with the comma, removing it gives this: >>> c++: error: unrecognized command line option '-Wl'; did you mean '-W'? >>> c++: error: unrecognized command line option '--no-undefined'; did >>> you mean '-Wno-undef'? >>> >>> -- >>> python programming - mail server - photo - video -https://sebix.at >>> cryptographic key athttps://sebix.at/DC9B463B.asc and on public >>> keyservers >>> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Lmuse-user mailing list >> Lmu...@li... >> https://lists.sourceforge.net/lists/listinfo/lmuse-user > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user |
From: Tim <te...@ro...> - 2018-01-13 21:59:12
|
OK just built DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined. Observed the errors! Hm, this is strange. The first error is this: CMakeFiles/al.dir/sig.o: In function `AL::SigList::ticks_beat(int) const': sig.cpp:(.text+0xc3): undefined reference to `MusEGlobal::config' C There's no problem with the sig module per se, it is just simply referencing the config variable. But the config variable is defined in another module, in gconfig.cpp In gconfig.h it is declared as: extern GlobalConfigValues config; So... what are we supposed to do? Hm. Checking... Tim. On 01/13/2018 03:57 PM, Tim wrote: > OK we just got /another/ report of this in the issue tracker, > someone packaging for Mandriva. > > Hm. So IIUC this problem may be because of my (our?) habit, > perhaps incorrect, of forward referencing a lot of stuff > in header files, so that I don't have to bring in a lot of other > headers in that header file, so that changing one small thing > in some small header somewhere doesn't cause a big recompilation. > > For example look at song.h, there are a lot of forward references. > > I had always assumed this was OK, since the symbols are eventually > found within the .cpp file. > > Ironically though, I was thinking heavily about the consequences > the other day - wondering if this habit might cause problems. > > And here we are. > > Does all this sound correct? > > If so, then we have a *lot* of changing to do. > > Or should we? Should the packagers do as the issue tracker > poster suggested he /could/ do and remove that strict > -no-undefined? He said this: > > "Since all the involved references are internal to the muse sources. > this means that muse is actually rather underlinked. I can workaround > the issue by forcing our build system to pass only "-Wl,--as-needed" > > "Perhaps this situation is safe, because all the needed symbols are > provided by other muse internal modules and consequently they are always > present, ruling out the chance of any runtime error; but I would argue > that it is better to have a properly linked program, if this is doable..." > > > Tim. > > > On 01/13/2018 02:20 PM, Sebastian wrote: >> On 01/13/2018 05:35 PM, Robert Jonsson wrote: >>> Thanks for packaging MusE. >>> First, if possible, add rtaudio as a dependency as it will allow >>> running MusE with other backends than Jack. >> I can't as rtaudio is not available in official openSUSE repositories >> (I guess because of license issues, it's only in a third-party repo) >>> As for the error I'm not sure what is going on, MusEGlobal::config >>> seems defined to me.. >>> I see this is happening while you try to create the package, does it >>> occur already when running ./compile_muse.sh ? >>> >>> Tim, you run openSUSE, right? Seen anything similar? >> This is not an openSUSE issue. The problem occurs during linking (not >> /compiling/). I'm not a C/C++ programmer but AFAI found out, the >> /--no-undefined/ during linking makes the linking process more strict. >> Without that flag, compilation works because the undefined references >> are /ignored/. Which does not mean that they exist, they reference may >> work after later linking steps but how that works is beyond my >> knowledge. As this flag is used for all packages in openSUSE that use >> cmake, I guess that muse >> Try building muse with the cmake parameter >> DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined and you should get the >> same errors. >> >> Sebastian >> >> P.S.: I don't see an issue with the comma, removing it gives this: >> c++: error: unrecognized command line option '-Wl'; did you mean '-W'? >> c++: error: unrecognized command line option '--no-undefined'; did you >> mean '-Wno-undef'? >> >> -- >> python programming - mail server - photo - video -https://sebix.at >> cryptographic key athttps://sebix.at/DC9B463B.asc and on public >> keyservers >> > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user |