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.

> To change the tuning, I added a button to InstrumentParameterBox, which brings
> up a dialog called TabTuningDialog. The dialog has a listbox, where you can
> add/remove strings. There's a little edit window to change the pitch and
> number of frets for the highlighted item. Also, there's an editable combobox
> for the name. I haven't implemented it yet, but I want to be able to
> load/save tunings to a file.
>
> I was thinking that this dialog could also service your auto-fingering code.
> It could either be through a button that would bring up another dialog or by
> just putting the appropriate edit boxes in TabTuningDialog.

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.

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

> The API should be really simple. With pitchAt(int), fretsAt(int), and size(),
> you can retrieve all the tuning information. Strings run from low to high.

You mean that 0 = low E and 5 = high E (in standard tuning), right?

Anyway, I think that if we can merge our two instrument definition classes then
you can simply pass a const pointer to yourself into me, so to speak.

> The only gotcha is the "start counting at zero" thing. I've been thinking
> about changing it to start counting at 1, since standard guitar literature
> talks about strings 1-6, not 0-5. I'm not sure if this would cause more
> confusion than it solves, since the typical loop statement
> 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.

> As far as the tablature itself goes, it's stored in the Event via the
> properties
> Rosegarden::BaseProperties::TAB_LINE
> Rosegarden::BaseProperties::TAB_FRET

Right. I'll upload some code tonight and point you at it.

Vince

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

Reply via email to