On January 24, 2016 10:35:17 PM Robert Jonsson wrote:
> 2016-01-24 19:15 GMT+01:00 Tim E. Real <[email protected]>:
> > On January 24, 2016 11:21:22 AM Robert Jonsson wrote:
> > > Good Sunday to all,
> > > 
> > > 2016-01-24 10:32 GMT+01:00 Tim E. Real <[email protected]>:
> > > > > 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.
> > > 
> > > Indeed a good idea, it's not like we can't distinguish between the two.
> > > 
> > > > 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.
> > > 
> > > You mean that we take this one step further, if we open a wave file, we
> > > assume it is an import operation?
> > 
> > Mm, no not an import, just a straight up load and replace.
> > Just like 'Opening' a midi file does right now.
> > 
> > 
> > So since that completely replaces, we need to auto-create a fluidsynth
> > track.
> > Similar then, for a wave 'Open'.  We auto-create an Audio Output track.
> > 
> > So then the user is ready to push play to hear the media. No hassles.
> > 
> > If they care to modify and work with what they've opened, great,
> > 
> >  it goes from there.
> 
> Ok, I see what you are aiming at. I can definitely see the use case when
> muse is launched.
> With the Open menu alternative however I find it improbable that the user
> will want to replace the current song with a wave file, atleast a warning
> should be issued in that case.

I was thinking ahead, if MusE's audio file editing capabilities become
 strong, people might want to just open a wave file to work on,
 accompanied by an auto-created audio output.
But then , I suppose how far to we go with that - what if they wanted
 audio inputs too. Maybe create one of them too.

A template could help here. Load it before loading the wave file.
One audio input, one audio output. I think we have one already.
Auto-set the channels and away we go.

And we could use a synth template to load before we open a midi file. 
(I will fix the assignment of the midi tracks to the synth, as mentioned.)
But the soundfont file location is hard-coded into the template.
I guess if we don't find it we can prompt for the location of it,
 or another suitable file.

Just some ideas. I'm sure it's all useful and we can work it out.

> 
> > > I was gonna say no, but why not? As I said, we can distinguish between
> > 
> > the
> > 
> > > file types, we can be fairly certain it should be added/imported.
> > > 
> > > > 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).
> > > 
> > > Yay, very good idea. We'll add the minimized fluidr3 to the muse
> > > installation then?
> > 
> > Mm, no I don't think so. It's a bit too big for inclusion.
> 
> It would be really good to include a file by default, I see MusEScore has
> opted for a minimized version of FluidR3. It seems they've invented a new
> file format SF3 (!). Haven't looked how it's done but the FluidR3Mono is
> only 10MB.

Holy cow. SF3. Compressed SF files.
But I don't see the point here.
Why ship a compressed FluidR3, being non-standard format too, 
 when the user can install the latest FluidR3 with one click.
Why not just make FluidR3 a dependency of the app?
Ah, maybe they're using the ogg compression strictly to save space
 while doing the decompression 'live' during playback.
Much like how we play ogg files.
But whoa, decompression takes time. I wouldn't go that route here.

We could ship a compressed FluidR3 SF2 file, then unpack it at install.
Oops, no, I just tried compressing FluidR3 and it yielded nothing.

So I guess my favourite is still this one:
> > I'd rather have MusE search for FluidR3, and offer to use another
> >  if it is not found.

Or just make FluidR3 a dependency of MusE.

Anyway no big rush, I'm fixing wave problems ATM.

Thanks.
Tim.

> > And of course this SF file will be settable by the user in Settings.
> > 
> > We look for FluidR3 in CMake, suggested but not required,
> > 
> >  and warn if not found.
> > 
> > Again, we're only storing a file name here, to be used and loaded
> > 
> >  if 'opening' a midi file.
> > 
> > * Note: There is a smaller SF file called Tim6MB, sounding just fine,
> > 
> >  which ironically is installed as part of...
> >  
> >   MusEScore !
> 
> Yeah I know of that one, as I wrote above it seems MusEScore has moved on
> though :)
> It is a splendid for a base alternative though.
> 
> > At first I thought it was part of Timidity, but no.
> > 
> > And then there is a smaller FluidR3, the 'Roland SoundCanvas'
> > 
> >  version. I can't recall if it is 'complete' enough for
> >  general midi. Will test again.
> > 
> > Now, /those/ two files are small enough that we might get away
> > 
> >  with including them in the MusE distro.
> > 
> > Certainly the Tim6MB looks like a good candidate, eh?
> > Can we 'borrow' it?
> 
> There is, or atleast used to be, a homepage for it stating the license, and
> it was quite safe to use as long as the license was with it (if I recall
> correctly). Seems it has vanished, will take some digging then..
> 
> /Robert


------------------------------------------------------------------------------
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

Reply via email to