On Monday 26 June 2006 03:34 am, Vince Negri wrote:
> somewhere. It looks like we (Michelle and I primarily, but of course
> everyone is invited :) should start hammering out the API between your
> stuff and mine.
>
> > Whenever the tuning changes, the tablature gets regenerated.
>
> When using my library, there are other events that should trigger a
> regeneration: (i) changing the algorithm (ii) changing the "hand
> model" and (iii) addition or removal of hints. I don't know if that
> has any effect on your considerations.
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();
};
There's some other stuff, like initialization, 'set' methods, etc.
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. Any changes to
tuning or fingering parameters sets the m_modified flag. When the dialog is
closed tablature is regenerated if m_modified is true.
This would be a high-level operation which is applied to the entire track.
There should (also) be a dialog just for fingering. Then you could select a
region and change the fingering just for that region.
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.
In memory, wherever staff type and tuning are stored (currently in Instrument)
the auto-fingering should go there as well.
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.
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.
Internally, the accessor methods look like:
int pitchAt(int stringNum) {return m_strings.at(stringNum);}
so it'll throw an exception if you pass it an invalid index. This makes it a
lot easier to find indexing bugs in the code.
As far as the tablature itself goes, it's stored in the Event via the
properties
Rosegarden::BaseProperties::TAB_LINE
Rosegarden::BaseProperties::TAB_FRET
Again, we have the same indexing gotcha. NotationStaff counts staff lines
beginning with 0. Since TabStaff is derived from NotationStaff, it does
likewise. Again, I'm not sure which way ends up being more intuitive.
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
