On Thu, 10 Nov 2011 18:50:45 +1000 David Seikel <onef...@gmail.com> said:
> On Tue, 8 Nov 2011 16:33:42 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Tue, 8 Nov 2011 07:23:27 +0100 (CET) Vincent Torri > > <vto...@univ-evry.fr> said: > > > > > > > > > > > On Mon, 7 Nov 2011, Carsten Haitzler (The Rasterman) wrote: > > > > > > > attached. this was a sample edc that would be able to play audio, > > > > not just single samples but whole sequences across multiple > > > > tracks as well as control specific channels and tracks. it didn't > > > > specify looping params yet or other additional stuff. > > > > > > i've never heard about that sound plan before the commit. The patch > > > was not public and we could not have discussed about it before the > > > commit. So I really don't like the way it came into edje. > > > > i'm not sure this is much different from anything else that goes on > > in efl. i have done work for a decade+ without discussing patches on > > the mailing list first. so have most developers. as such this patch > > this time was going through me. the comments on the patch so far > > havent actually commented on the edc api it adds at all which > > everyone is up in arms about "for release". so since everyone > > complaining isn't actually talking about that... i'll write it here > > in short form. it adds: sounds { > > sample { > > name: "<NAME>" <ENCODING>; > > source: "<SAMPLE_FILE>"; > > } > > ... > > tone: "<NAME>" <FREQ>; > > ... > > } > > and 2 more actions: > > PLAY_SAMPLE "<NAME>" <SPEED>; > > PLAY_TONE "<NAME>" <DURATION>; > > > > that's it. unfortunately to make this WORK u need a chunk of infra > > like being able to load and encode samples into edj files, decode > > them, play and mix them, resample them, etc. all of which is opaque > > to the api. > > /me picks a spot in this thread to actually discuss the API. Here > seems the best. hooray! :) > A quick look over it, and the example, and the "plan", and it seems > mostly sane. One thing that stands out straight away in the examples is > the way that a bit of music was defined. > > First thing is that you are using something that looks like a typical > tracker, which is fine in itself. Lots of people are familiar with > that. It's a bit verbose though. well my hope actually was that later we can provide a mod/xm/s3m converter that can load one of these files and produce a bunch of edc to include. the only reason i didn't go right to "use libmikmod and just inline mods in your edj" was that these mod formats don't support ogg/mp3 etc. style sample compression and i really want that for space efficiency reasons. i actually wasn't expecting peolpe to write music in edc. it's POSSIBLE and to be honest - when i did tracking you literallly did almost what the edc says in text. u arrow down 7, hit a key to play the sample at that speed (c-3/b-3/f#-2 etc.). you'd literally just have the sound played at that time as the added bonus.. :) > I think it would be great to also provide an alternative that is more > like MIDI, as that is also used by a lot of people. Have both, that > would cover most things. Actually, the "plan" includes using a program > per note, which is a bit more MIDI like, but even more verbose than the > pattern style. a program per note would be bad. programs dont guarantee any timings of any sort. if u want N channels synced you're in trouble. :( but if u want to use embryo.lua then u can write CODE to play but u'll be writing code to have a timer and call play funcs... maybe from a passed in table/array.. but it'll boil down to the same thing. can you expand on the midi thing with some details? last i knew of midi it was roughly the same as a single track of a tracker with no defined length - just commands to "play instr id X at note Y" like thngs - much like a tracker. > Can we cut the verbosity levels? Though I guess edje has a similar > problem, and the solution is to go to embryo, or lua (which so far > seems to end up being about half as verbose as embryo, though YMMV). i'd say the verbosity is on par with a tracker... is that bad? > Second is what you are doing to provide a scale. I see you are > basically dividing an octave into 7 equal parts, then doing maths to > arrive at the numbers to feed into the system. Now I'll admit that oh.. thats just making use of edje_cc's math handler. speed is 1.0 for "play note at given samplerate" ie - if sample is 44.1khz - then play at 44.1khz. 2.0 == play at 88.2khz. 0.5 == play at 22.05khz etc. edje_cc can do inline math expressions it evals at edje_cc time, so (3/7) becomes 0.428 - it's just me making it more convenient. i guess it doesnt work well for < 1 but for > 1 it works well. > musical scales are an entire morass of systems, but most western modern > and classical music, going back a few centuries, uses the 12 tone equal > temperament scale, or something very close to it. Except for blues and > jazz, where things can get complicated. Non western music uses a > variety of scales, so it's hard to do one size fits all. Like most of > western culture though, it's becoming the most popular around the > world. I have idea what traditional Korean music is like. yeah - i know. here come the catch. the actual note... is entirely irrelevant. the note means zip when it comes to the pitch of the sound as it's entirely dependant on what u sample. what i do know is that its an exponential scale. play a sample at 1/2 its nominal rate, it drops 1 octave. play it at 2x its nominal rate, it goes up 1 octave. repeat. (4x and its up 2 octaves, 1/4 and its down 2 octaves). so as such notes mean nothing when u have generic samples. it's up to the "composer" to deal with that as all they want is RELATIVE notes. :) from memory trackers would take the base samplerate to be "c-6" (c 6th octave) - we can provide macros or enums/short forms for all of the notes and octaves (c-6,d#6 etc.) but these too end up becoming just a sample playback speed 0.0 -> 1.0 (nominal) -> etc. for higher pitch. :) > 12 tone equal temperament scale divides an octave into 12 equal > parts based on the 12th root of 2, coz things are logarithmic. People > doing basic music stuff should not have to deal with that sort of > maths. lol > > On the other hand, I think the API Should provide something more like > scientific pitch notation, as it's easy to write that in ASCII, if you > use "b" to mean flat. Then the maths for 12 tone temperament scale is > hidden, and music comes out sounding like it should. Could be done with > some macros. So you could provide "notes" like - > > C C# D Eb E etc. as i said - we can make it part of the parser, but it still then boils down to a float value. at this stage thats a convenience, not a fundamental issue. :) > Not sure about specifying octaves above or below the reference sample > or tone, standard scientific pitch notation refers to absolute > pitches. Note that this would be an option, people dealing with not so > common scales can use that as an example, do their own research into > the maths behind their scales, and still be able to use the correct > numbers that suit them. trackers did it this: (octave 1) C-1 C#1 D-1 D#1 E-1 F-1 F#1 G-1 G#1 A-1 A#1 B-1 (octave 2) C-2 C#2 D-2 D#2 E-2 F-2 F#2 G-2 G#2 A-2 A#2 B-2 etc. - all of these really equated to non-fine-grained ways of multiplying the nominal samplerate of the sample. if you wanted speeds other than the given notes u use modifer commands that fine-tune adjusted samplerate from the given note. there ere 256 levels allowed between notes with the fine-tune cmd (trackers allowed up to 256 commands/modifiers too). c-6 equated to "play sample at its samplerate" and all other notes above ands below just adjusted playrate accordingly. we can do this - but it does boil down to playrates relative to 1.0 :) > This is just a quick look. I'll go over it more later. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel