Re: [linux-audio-user] png graphics library for sound apps

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] png graphics library for sound apps
From: Rick Taylor (ricktaylor@speakeasy.net)
Date: Wed Jan 29 2003 - 12:21:39 EET


On Tue, 2003-01-28 at 18:35, David O'Toole wrote:
> > http://www.gnu.org/software/octal/ox_api_main/index.html The guy that
> > put this page up originally mentioned something to the effect that
> > electronic music required a new language...
>
> Hello, I'm the guy that put that page up :-) I'm not sure if I remember
> what I said about needing a new language; although my project is being

 I interpolated a bit... You mention {actually on creativelinux} that
you're not awfully fond of existant language oriented synths or of midi.
I just think they {synths} need an alphabet. Midi seems a bit too
specific to non computer functions.

 What I'm really talking is a sort of consistent, simple method of
determining the contents of those mysterious little boxes and
machines... I realize that text is pretty accurate... It doesn't travel
well. "Delay" in English isn't real readable to folk in India, for
instance... On the other hand if you had a consistent character set that
could be mapped to a font the learning curve would be considerably less
steep. It might be nice to be able to simply type an idea or even use
ideas as modules {gnome think}

 A vector format {did you see my last message?} aside from being easily
extruded into 3d forms would be scalable and easy for folk to use... It
would make banks of effects, patches etc easy to work with. Perhaps one
could even fontify the effects and samples themselves or at least alias
them... then you could just type a musical phrase. If you search
www.databaseaudio.com folk are doing some nifty stuff with flash... the
format's suited...

 Add things like color mapped to the frequency of specific sounds {by
the computer.} ...So that when you adjusted the frequency the color
would change accordingly... you could map volume to size... move into 3
dimensions and you've got the added descriptors of height, distance,
reflection, all the properties of light and so on. The interface could
fairly accurately represent the music... and, inversely the music would
influence the onscreen display... From there you get all sorts of truly
multimedia possibilities...

 To take it even further... you could actually model sound
graphically... nurbs, beziers, etc...

 ...I'm seeing this as much more effective than the staff and... it's
unique to computer music.

> built around a scripting language of sorts, it is not intended to be a
> visual modular-synth construction kit or anything resembling MPEG-4 SA.
> I've got something else in mind.
>
> I'd like to hear about your idea in more detail. It seems like you're
> talking about an interface that docks all its interface windows in neat
> rows rather than having lots of overlapping windows. Perhaps the
> sub-windows are collapsible, and leave behind a little labeled icon when
> collapsed. Sounds neat .

 I suppose you could implement it that way.

> I'd be more inclined to define the common set of icons in a vector
> format, but I guess that's open to discussion.
>
> ---dave (dto@gnu.org)
>
>
> > > > What about iconic/language type stuff like live uses?
> > > >
> > > > ...more of an audio alphabet than fancy graphics. You could get some
> > > > standardization going and make things easier and a little more object
> > > > oriented.
> > > >
> > > > If you get that in place then folk can start messing with the symbols.
> > >
> > > hmm... im not entirely sure i understand what you're getting at....
> > >
> > > i've used Live... do you mean their use of abstracted, symbol-like icons
> > > intsead of realistic looking knobs?...
> >
> > Sort of... I'm thinking along slightly different lines though.
> >
> > {I've actually been giving this a good deal of thought over the past
> > hour or so.}
> >
> > If you were to define some sort of grid or matrix in xml so as to
> > provide folk with a lot of empty spaces to fill with plugins {engines,
> > sounds and so forth} and then go back and define a symbol for each of
> > those spaces {function, sound, type of connection} giving some thought
> > to syntax and function within the matrix {possibly extending this into
> > other dimensions at some point} you'd have the beginnings of a sort of
> > universal {electronic} musical language/application.
> >
> > Keeping things simple and iconic would allow you to redefine and extend
> > things {you might take a look at this:
> >
> > altogether suited {as well as being a bit limiting} ...to illustrating
> > electronic musical concepts {We need to be able to represent them quite
> > differently... a stream of characters {a custom font} or flowcharted or
> > placed on a 3 dimensional grid, etc...}
> >
> > It would be much easier for folk to simply build grid elements so you
> > could extend or modify or replace specific parts and functions of the
> > grid than to remake the entire thing every time one wanted to create a
> > new application. {form being massively tied to function here} All you'd
> > need to do would be string together different elements of it. Arts and
> > Octal and Gnome-Think and pd and buzz, etc already have a sort of
> > framework in place for organizing information this way... I think what
> > we need is an object catalog... a language. It needs to be universal and
> > standardized. Symbols need to be defined for specific modules so as to
> > make things easly understandable. It's a higher level method of
> > organizing high level concepts.
> >
> > I think it probaby needs to be moved into the third and possibly 4th
> > dimension as well. Otherwise it's going to get to be really difficult to
> > keep the relationships between functions clear.
> >
> > So.. yeah... abstracted and symbol-like is more appropriate. 3
> > dimensional with some means of representing placement in time are
> > probably good too.
>
> --
> David O'Toole <dto@gnu.org>
>
>


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 12:24:58 EET