Re: [raga-genome] Complexity - Sufficient and Necessary
Vidya Jayaraman
Deepa Mohan
Suraj Kumar
On 7/19/06, Vidya Jayaraman <vidy...@gmail.com> wrote:
> What exactly is this project?
>
> Merely trying to create a database of ragas (the difference being you also
> add other attributes other than the ascent and descent scale + enable some
> future layered applications to be built upon this?
Database is not the goal. The goal of our effort (to collect
requirements, design and code) is to make a platform. We can worry
about using the platform to create ragas, etc.,. (but do read on to
understand more :) ).
> If so why would a user (as opposed to an administrator/data creator) want to
> create raga genes? Room for error,inconsistency etc ..
No. Think of a wikipedia for ragas -- the community contributes, the
community polices. Except this is not literally a wiki. Its a tool
built just for collecting and accessing information on ragas.
> Also if someone wants to browse through the contents what is the interface
> he/she sees?
We (Pravin and I) have a rough idea. The user either searches for a
raga and finds a 'cloud' of genes that characterises the raga. genes
are tagged into groups called arohanam, avarohanam, jiva-swaras,
sancaras, etc.,. OR the user looks for specific phrases (genes) and
sees what ragas have such genes. The user can keep 'browsing away'
from one raga to another based on how similar they are.
> We can throw in a million complications such as Sruti,inflectional
> variations such as the 'Ni' in Begada being in between the two Nis in some
> places.Yet it is possible to define an empirical raga form (atleast for some
> of the ragas) for as many as 100 ragas without going into these.
Why leave out the rest N-100 ragas? I completely agree that the
prototype must be built... but remember we are looking at building a
platform and our prototype should give us a good demonstration of its
abilities. The ragas that we will use (like you said, 10 or so) will
only be from the point of view of making sure our platform can handle
it and if it doesn't... we go back to the drawing board. :)
> Which is why the only way to see if the framework is really feasible is to
> build a tiny prototype.
Correct. But before we go on to do the prototype I think it is
important we get the following right:
0. What we want to achieve
1. Requirements
2. Design
> Again there might be a lot of sancaris in say a raga like Todi.How much
> should we limit it to? Ie what are the sufficient and necessary conditions
> for Todi..This is where the gene concept fails us.If you take each raga as a
> set Todi{ 'phrase A.'phrase B' etc, "Important Note' , landing note, other
> properties} you still might be able to have a workable practical model
> (which improves upon the scale system but still might lack all complexities
> of a raga)
Like I said in earlier (and in the other email[1] to Hari) the
community will keep adding this info. Volunteers will police the
information and check for integrity. Once the community grows
substantially we will have decently 'dependable' information.
To give you a rough time-scale of how I think things will happen:
* Launch on Day X
* On Day X+365 we will have something that is (only) as good as one of
the many 'raga information' sites. But then, you can never
under-estimate the power of the community :) I would love to be
surprised :)
> So I would say let us try to go ahead and create a format to save this,
> create an interface and see if we can capture it..A wheel that moves is our
> goal, we can add more cogs and complexities as we go? That is my 2C
I agree with this.
Pravin, let us talk sometime over IM on where we can start. 22 vs 12
notes, meter-limitations, sthayi limitations, etc.,. are already good
enough info that we have. We can try to create some simple prototype.
What say?
--
Freedom from the Human Condition: http://actualfreedom.com.au/