Thanks rajesh.
rajeshnat wrote:1. The fonts that you are tyring to provide can be removed .You can use just the standard font like arial ,sans-serif internally to reduce the confusion.You dont need to provide a user to select different fonts . I see the value of bolding and italic.Eventually all this is html-presentation content.By giving fonts to end user , the usability experience will not be consistent
I would have to disagree. IMO good WYSIWYG editors should recognize that different users have different visual preferences. This is like the difference between say "notepad" and "wordpad/word" (for creating even simple documents).
Although from a portability standpoint (i.e. exchanging stuff) you can run into more trouble, e.g. if you may pick a font on your computer, which is not on your friend's computer. So for maximum portability (say notation meant to go to a shareable database), you want to stick to "standard" font families - or even just the default font (so no font selection).
But again, i want to emphasize "exchanging notations" while important is not necessarily the overriding use-case of this app. Notations can vary significantly between books - unlike for western classical music. So while having a single database can be of some help, there is no such thing as "authoritative notation" for most pieces. Given that exchangability between
any two people (as opposed to students of same school) can be of limited use. Also "learning from notation" is
not really a CM thing again unlike western classical music. You can give notation for a "new song" say in kalyANi to a experienced CM person and he/she can figure out the krithi - but chances are he/she is going to apply his training's stamp on it and thus "change it". Thats the nature (and beauty of) CM - it allows different interpretations and hence is not mechanical. Sorry for the ramble - but my point is personal preference for type-setting should not be under estimated in my opinion.
rajeshnat wrote:2.YOu are defining the structure of the song as gamAkas,duration,stayi and label. They are all to me the xml attributes of the song Are they complete? .Do you need anything more??
I presume you mean swaras rather than song. No they are not complete (anya swara indication are missing). Even gamakas is a challenge - again some of the gamakas in SSP are very specific to playing on vINA and may not apply to vocal. I may be wrong, but due to lack of standardization of gamaka representation (for vocal vs vina vs flute etc.), people have their own schemes. Ideallly the program again should allow for them to represent their own scheme besides any standard schemes. I havent figured out how
Also, its possible there is more. I am open to suggestions.
rajeshnat wrote:A dumb question , suppose one wants to emulate MMI and MDR, will they stay the same or are we going to only document the common denominator
I am not sure I follow. But you will have very very different notations for the same krithi as MMI and MDR would sing same krithi very very differently - and neither one would be "the standard"
. But again - that is just how CM is
. Also I dont think there is a common denominator - its not that the underlying swaras would be identical between MDR's and MMI's renditions and they just intonate it with different gamakas. There will always be more fundamental changes.
rajeshnat wrote:3.It is significant task for you to intermix xml and html information in one file .Maybe you might have already found a solution.I am little worried with your demo in terms of execution when you mix both content and presentation.
. I can see where you are going. But I did find a solution. The xml content is embedded as a singular unit in HTML (<XML> blah ... </XML>) -> there is no "inter-leaving" if you will. The HTML file has very little info regarding HTML styles - as the actual notaton content is in DHTML done from javascript (so HTML file includes js files), and of course there is a bit of CSS stuff.
I did the combined HTML+XML mainly for convenience, so that normal users can load/edit their notations in one-shot. But in any case, I was definitely planning to save the XML contents alone into a XML file (and also load a XML file into the editor). This can be done easily again because the XML part is saved as a single contigious chunk.
In fact, I am 50-50 now on whether to allow a single combined HTML or not.
Having a HTML file pointing to a separate XML file is a possibility, but I am not sure my current solution would work.
rajeshnat wrote:4. A better solution is you providing three views as three tabs in a desktop application that you suggest. One is your view as explained in the demo .Other is a xml view where user is allowed to hand edit the file directly and the other is a html view which is rendered in the browser view within the desktop application. All Html styling is not given to the user to facilitate the clean storage of xml.
Writing a desktop application is not what I want to do now - its too much work
:). The big big job in the app is the layout, and I am basically reusing the browser's layout engine for that. Besides, again, browsers are widely accessible etc. etc.
So at this point I am not thinking of desktop appl. Maybe in the future.
But once saved XML file, i think any XML editor can be used to edit. Or you could even use a text editor (but see next point)
rajeshnat wrote:To illustrate your tool better,You show them one sample brovabArama as an example with all three views when they download the application. They will copy that sample and edit that copy while saving as another file name for a different krithi that they take up. The idea of providing them with a seperate browser html view for a user in the desktop application to get the feedback that they are doing it right.
Again not sure if you mean, but taking an existing krithi as a template for a new krithi is not a good idea. The notations are going to be completely different. I think all you need to do is create a krithi of appropriate tala, look at your pATTu-pustakam or other source, and just start typing away
(ok i am exaggerating because you have to adjust for speed etc.). It is really much much easier than XML file editing.
Now you may not buy this, but creating correct notation for a krithi is not a straight-forward job as say typing up lyrics, or even typing notation for a varnam. Krithis use a lot of swaras, lot of mixture of speeds etc. (but you may see thiis perhaps only when you actually try doing it).
That is why a visual editor (which takes care of the layout, putting tala etc.) is going to be lot more useful for most people, much easier than an XML editor (and much much much easier than typing in raw XML in a text editor
).
But, i do a have a "simpler" text/ascii format in mind which can be typed in fairly easily (for power users) and this can then be either convered to XML format or loaded into the visual editor. Carnatic music notation (or for that matter any notation) is quite complex and ca
rajeshnat wrote:Once done every user will consolidate his work and push only the xml to one master site. That feature is needed.
This should be possible. As said saving as just XML should be possible - and hence posting that content to some master site should be possible (although i am not signing up for providing the infrastructure/logistics etc. for that master site
).
rajeshnat wrote:5. After seeing the demo of yours, what is needed is a Distributed desktop solution which is a good alternative for all content editors for different languages which you have in mind.
Here I am assuming that providing editing capabilities in internet thin client environment is a far cry not reaching reality.Then once when the xml is stored we will upload to one website which will be used by most of us , where the xml is converted to a consistent html data .
Perhaps. But what I was thinking for "non-english" language was not necessarily data entry in that language (i.e. you dont type notations directly itself in Sanskrit/tamil) as that would mean foreign keyboards etc. I was think you specify a non-english language, and transliterated scheme, and the data-entry would be in "transliterated english". The program will translate it to the unicode stream for that language and assuming you got the necessary fonts, the browser should render it in that language. I have done this in a different environment (i.e. the automatic translation part).
Arun
But using baraha it is possible to transliterate to any language (that we are interested - telugu, kannaDa, tamizh and dEvanAgari) once you have a text in roman alphabet. I am not sure if that is something that would be useful for your project.