On 29/06/06, Michelle Donalies <[EMAIL PROTECTED]> wrote:
>
> After looking at your class, a merger looks like a good idea. I'm kind of
> thinking on the fly here, so my comments might come off as a little
> disjointed.
>
> First thing is that I put the tuning stuff in the base directory, since it
> doesn't have anything to do with the gui directly. If it's going to go there,
> it should use vector instead of QValueList (because of the Qt restriction in
> base, though with the current state of RG, that restriction seems a little
> artificial).
It does seem a little odd to me too, since QT is not a purely GUI
library. I use it for pure console-mode apps all the time. But of
course if we are going to stick to keeping base clear, then there
isn't a technical obstacle to using vector at this point. I do see my
tabgen stuff as being a library that RG links in, though, so apart
from the API it isn't anyone's "business" whether I use QT internally.
> Second, we may be able to broaden the scope of InstrumentDefn. RG's Instrument
> class goes in Studio, which is mapped in with the sequencer. There's no place
> for such basic information as what type of track we're dealing with (midi,
> audio, softsynth) without accessing Instrument, which means the sequencer has
> to be running. InstrumentDefn might be a good place to put this info.
Well, InstrumentDefn is - er, an instrument defintion, so this makes
sense! Although coming back to ensuring the reusability of the code as
a standalone library, I would prefer to see something like a
RGInstrumentDefn that inherits the basic Holdsworth::InstrumentDefn.
> I'm not sure what the RG limitations will allow, but ultimately I would like
> to have considerable flexibility in setting up an instrument. Things for
> further down the road include MIDI channels (guitars really need 2),
Don't they sometimes need 6, for portameno per string?
> 12-string guitars (each string needs to sound two pitches), and the like.
> I'd like to be able to set up an instrument and be able to save the settings
> to a file. I have a small set of guitar types that I use frequently -- std
> steel string acoustic, std nylon string acoustic, std 24-fret electric,
> 22-fret electric tuned down 1/2 step, std 22-fret bass, and mandolin. It
> would be nice to set up for these instruments once and then attach them to
> tracks as needed.
Definitely.
> > Are you thinking of storing the tuning in XML? Perhaps I could
> > arrange it so that the auto-fingering class can persist itself by
> > handing a QXMLDomThingy to you to write into the same file. That way,
> > the presets consist of an instrument, and your favoured settings for
> > the instrument.
>
> Yes. Since the current values for staff type, tuning, etc. get stored in the
> the .rg file anyhow (I added some stuff to RoseXmlHandler to make that
> happen), it should be a simple thing to save a portion. Just call
> TabTuning::toXmlFile() to get back a string that looks like:
> <tuning name="2-string guitar">
> <tabstring pitch="40" frets="22"/>
> <tabstring pitch="45" frets="22/>
> </tuning>
Looks eminently reasonable.
> I'm currently using 0-based throughout, switching to 1-based only for the gui
> boxes. Because the staff is 0-based, I supposed it's simplest to make
> everything that's not a gui display follow along with that.
Ok.
>
> void TabAutoGen::compute(vector<Segment*>& segList)
> {
> // for each Segment
> // for each Event
> // get the pitch
> // do computation
> }
Well it's not a straight looping over the individual notes. Because I
perform multiple passes and take into account the whole note set, your
compute would look a bit more like this:
{
//for each Segment
//build Holdsworth::NoteList from notes in segment
//call Holdsworth::Engine::compute
//retrieve fingerings and insert back into segment data
//end for
}
..but that's an implementational detail :)
> Anyway, however you think it should work. I think that Segments are artificial
> break points useful for manipulation in TrackView. As far as tab generation
> goes, I don't think the computation should "start anew" at each Segment. You
> might think differently, though, and in any event, the "start anew" approach
> is the easiest to implement.
Strictly speaking, I agree the computation shouldn't take account of
segment breaks. In practice, though, quite often the segments will
correspond to phrases and starting afresh will yield reasonable
results.
> One thing that does matter, though, is that the Segments are on the same
> Track, since different tracks may have different tunings. So maybe
> void compute(TabTuning&, Segment&);
> is the best approach (with the tuning local to the compute and not a class
> data member). Given the current state of RG, this is what I would probably
> do. It looks to be the simplest by far.
I say we start off with something simple like that.
> I don't have access to the computer with my tab stuff on it right now, so I
> can't post any files. Hopefully next week -- probably after Tuesday. :)
Okay, I'll look at making my external API accessible in a "QT-free" way.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
