On Tuesday 27 June 2006 07:36 am, Vince Negri wrote:
> On 27/06/06, Michelle Donalies <[EMAIL PROTECTED]> wrote:
> > I created a class for the tuning called TabTuning. Essentially, it looks
> > like:
> >
> > struct { int pitch, int frets } TabString;
> >
> > class TabTuning
> > {
> > vector<TabString> m_strings;
> > string m_name;
> >
> > string& name();
> > int pitchAt(int stringNum);
> > int fretsAt(int stringNum);
> > int size();
> > };
>
> That's very similar to my InstrumentDefn class. I think we should look
> into a possible merger of the two (or putting them in an inheritance
> relationship, or what have you) as that would simplify the code.
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).
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.
So InstrumentDefn could hold InstType (midi, audio), StaffType (Std, Tab,
Audio), TabTuning (or StringTuning or whatever we want to call it), and
TabAutoGen (or whatever it should be called, which would be the default
fingering model, algorithm, etc.).
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),
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.
> That makes sense. After the tuning, handmodel and algorithm, all the
> user "preferences" are encapsulated in one class. Probably the
> handmodel and algorithm can be simple combo boxes in TabTuningDialog,
> and the other prefs (which are all guru fine tuning options) could sit
> behind an "Advanced..." button.
That sounds reasonable.
> > I'm thinking that just in the same way that the tuning gets a name and
> > can be stored in a file, the auto-fingering stuff should do likewise. For
> > both things, it would be good to have a list of customizable presets.
>
> Yes. 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>
> You mean that 0 = low E and 5 = high E (in standard tuning), right?
Correct.
> > for(int i=0; i<tuning.size(); i++)
> > changes to
> > for(int i=1; i<=tuning.size(); i++)
> > I'm not sure which way is more intuitive.
>
> Neither am I. I think I output 1-based at the moment, but use 0-based
> internally.
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.
To sum up, I'm thinking of something like:
class InstDefn
{
public:
typedef enum { Audio, Midi, SoftSynth} InstType;
protected:
InstType m_instType;
};
class MidiInstDefn : InstDefn
{
public:
typedef enum { AudioStaff, StdStaff, TabStaff } StaffType;
protected:
StaffType m_staffType;
};
class TabInstDefn : MidiInstDefn
{
protected:
TabTuning m_tuning;
TabAutoGen m_autogen;
};
class TabAutoGen
{
public:
typedef enum { StdAlgorithm } AlgorithmType;
typedef enum { StdHand, HoldsworthHand } HandModelType;
TabAutoGen( const TabTuning&, AlgorithmType, HandModelType );
void setConstraints( /*whatever*/ );
void compute(vector<Segment*>& segList);
void compute(Segment *seg, timeT start, timeT end);
void setAlgorithm( AlgorithmType );
protected:
AlgorithmType m_algorithmType;
HandModelType m_handModelType;
Constraints m_constraints;
TabTuning &m_tuning;
};
void TabAutoGen::compute(vector<Segment*>& segList)
{
// for each Segment
// for each Event
// get the pitch
// do computation
}
Currently, RG doesn't have a simple way to get the Segments in a Track. This
goes back to earlier complaints I made about the loose coupling of Tracks and
Segments. Once you get more than one staff type, things become needlessly
complicated. What you really want is to be able to pass in a Track& and
iterate over its Segments.
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.
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 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. :)
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
