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

Reply via email to