On January 24, 2016 09:44:48 AM Jens Radloff wrote: > Hi Robert, hi all, > > Let me answer some of the mails from yesterday and two days ago. I just > compiled and installed the latest git version. > > Robert wrote: > > Hi Jens and thanks for testing, > > Your welcome :-) > > --- > > Robert wrote about the "Add wav track" functionality: > > Maybe it should be called audio file > > since we support more than .wav. I > > have a feeling renaming may affect > > a lot of things though. > > I would not call it "Add audio track"/"Import audio file" because midi > and even med files are audio files, too ;-)
Midi and med files are not audio. I think there was some confusion there, Jens was describing the missing wave part event and being very thin too. Anyway, about that naming, maybe we should just unite the two midi and wave import functions under one 'import file' item. I want to propose that we add the ability to 'open' a wave file, not just import it. Notice that our file open dialog filter box says "all known files". Thus we should include wave file there. The reason I say that is that I'm working out the ability to 'Open' a pure midi file and auto-load a fluidsynth track with a pre-loaded soundfont (the FluidR3). There will be /no/ usual dialog, warning, or didyouknow boxes to pop up, and get in the way, and ruin the experience. (Unless there's an error of course.) Thus MusE attains a sort of 'media player' mode, where you just load and play. Like 'Open with MusE' menu associations, 'clean' command line opening, etc. So... If we add wave files to that open dialog, we can load the file, and an Audio Output track, and the user is ready to play. Summary: 'Open' a midi file: Auto create a fluidsynth track. 'Open' a sound file: Auto create an Audio Output track. 'Import' a midi file: The usual two options of replace or add. 'Import' a wave track: The usual options. Note: Someone once complained to me that 'importing' a midi file did not automatically assign it to a synthesizer track if one already existed in the track list. It assigns to hw ports. I replied that half the people might want the midi tracks to be assigned to the first hardware port(s) found, and the other half might want the synthesizer, so it was arbitrary. That's stuck in my head all this time. But now I think I will try to assign the midi tracks to the first available synth track, and if not /then/ the first hw ports. Thinking of doing that very soon. All in the name of opening and playing media faster/easier. "Easy listening." T. > Maybe one can call it "Import file in another audio format" in the File > menu. And "Add track with another audio format" in the context menu if > one right-clicks below the "Out 1" track and other possibly existings > tracks. > > --- > > Robert wrote about my ogg file which is not properly displayed in the > > Arranger Window: > > Do you have an ogg file that > > has this problem you could mail me? > > I guess there is no need for this anymore because the behaviour is fixed. > If not, please let me know, Robert. > > To be precise what I tested regarding this issue: > > 1. I opened the med file containing the ogg file which I imported some > days ago (before the latest update of the MusE git version), and which > showed no sound information after the first seconds in the Arranger > Window some days ago. Now, with the latest git version installed, this > ogg file is still wrongly displayed (no sound information displayed after > the first seconds in the Arranger Window). > > 2. I then imported the same ogg file again in the same med file, this time > into a new wav track. Result: the ogg file which I imported in the new > wav track is properly displayed in the Arranger Window (all sound > information displayed to the end of the ogg file), and the ogg file which > I imported some days ago, too. > > => Ogg files in med files which were created before the latest MusE git > version had been created, are still not properly displayed in the > Arranger Window. They need to be re-imported, to ensure that they are > properly displayed. Should this be fixed considering the upgrade of MusE > 2.x installations to 3.0 when MusE 3.0 is released? > > --- > > Robert wrote about resetting the background in the Arranger Window: > > Try the clear button, it worked for me. > > Works. Thanks, Robert. > > --- > > Robert wrote about the behaviour of the "Apply" button in the Appearance > > Settings window: > > I added an explicit raise(); to both > > configuration dialogs. > > Works, thanks, Robert. But the Appearance Settings window and the whole > MusE GUI flickers shortly if one clicks the "Apply" button. > > --- > > Regards, > > Jens ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
