Carsten, a few people have noted their disappointment (and anger) at this
being merged and some requested it to be reverted, you didn't even take the
time to answer them and address their concerns.. Could you please take the
time to do that, since you obviously had time to respond to David with such
a long email, it looks bad for you to respond to only what you want and
ignore everyone else.
On Fri, Nov 11, 2011 at 1:33 AM, Carsten Haitzler <ras...@rasterman.com>wrote:
> 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
>
------------------------------------------------------------------------------
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
