[Octal-dev] Re: Octal-dev digest, Vol 1 #15 - 11 msgs

[VINCENT CRUZ]

address@hidden wrote:

> Send Octal-dev mailing list submissions to
>         address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.gnu.org/mailman/listinfo/octal-dev
> or, via email, send a message with subject or body 'help' to
>         address@hidden
>
> You can reach the person managing the list at
>         address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Octal-dev digest..."
>
> Today's Topics:
>
>   1. suggested features (Guenter Seethaler)
>   2. Re: suggested features (dave)
>   3. Re: suggested features (dave)
>   4. Re: suggested features (Danny P.)
>   5. Re: suggested features (Dave O'Toole)
>   6. Re: suggested features (Danny P.)
>   7. Re: suggested features (Luka Frelih)
>   8. Re: suggested features (=?iso-8859-1?Q?G=FCnter_Seethaler?=)
>   9. Re: suggested features (Dave O'Toole)
>   10. Tex/LaTex was: [Octal-dev] suggested features (Rettschlag Dirk)
>   11. Re: suggested features (Helmut Orian)
>
> --__--__--
>
> Message: 1
> From: address@hidden (Guenter Seethaler)
> Date: Thu, 27 Apr 2000 20:55:06 +0200 (MET DST)
> To: address@hidden
> Subject: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> Hi to all!
>
> I compose music with trackers since the AMIGA time.
> Now I'm using folloing software on Win98:
> BUZZ
> ImpulseTracker 2.14
> Cubase V3.553
> WaveLab V2.0
>
> Each of this programms have their advantages/dissadvantages.
> What i want is a mixture of all these programms.
> Since i didn't found one, i started to write by myself in Delphi4.
> The main design is pretty close to that of OCTAL.
>
> So far i have the output, two machines(Drum, Bass), the mixers and one track 
> for
> each channel running.
> And there is a Development GUI for editing the track-notes and changing the
> machineparameters and mixer Volume/Pan.
> (if anyone wants the source/binary feel free to contact me:
> address@hidden -- running just on WIN9x)
>
> After playing with this little tool there is one conclusion: The
> machine interface is the most importend module of the hole thing.
> Some ideas:
>
> VARIABLE MACHINE PARAMETERS:
> think of an volume/pan/frequency...  envelope.
> it would be fine for the user to add/delete points to the envelope at runtime.
> so we need some sort of variable parameter.
> this is also usefull for a sine-wave-generator with  "over waves" -
> (sorry my english is not the best, but i guess you now what i mean).
>
> -------------------------------------------------------------------
>
> VIRTUAL MACHINES:
> the user can connect some machines and create a new machine of this
> set.
> this virtual machine acts like a normal machine. plus it also can be
> used in other virtual machines.
> For Example:
>
>                 VIRTUAL MACHINE
>              ------------------------
>              |  sine-wave-generator |
>              |          |           |
>              |    Volume envelope   |
>              |          |           |
>              |       filter         |
>              ------------------------
>
> ---------------------------------------------------------------------
>
> MIXDOWN MACHINES TRACKS PATTERNS :
> Softwaresynthesis consumes lots of cpu-power. (i have 166Mhz Pentium).
> So there is always a compromise between
> the number of Machines and the Quality of them.
> To work around these problems we can mixdown tracks, patterns and
> sequences to waves.
>
> The Sequence Editor:
> I think of an editor you now from MIDI-sequencers. But instead of this
> unuseable note editor, we use a tracker interface.
>
> This leads me to the idea of using an event triggerd synthesizer. The
> advantage of this: you can have an midi-interface. But i don't know
> yet how to realize that.
>
> -----------------------------------------------------------------
>
> WIDGETSTYPES:
> MULTISWITCH: this thing has 2 to n states. each state has a text-description 
> to know the actual state.
> Example: Filter: LOW MID HIGH
>
> -------------------------------------------------------------------
>
> Thats for now (got to go home),  but there is a lot more to discuss.
>
> happy hacking
>    Magus
>
> --__--__--
>
> Message: 2
> Date: Thu, 27 Apr 2000 14:50:55 -0400
> From: dave <address@hidden>
> Organization: x
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> > What i want is a mixture of all these programms.
>
> > After playing with this little tool there is one conclusion: The
> > machine interface is the most importend module of the hole thing.
>
> Do you mean the user's GUI, or the programmer's API?
>
> > VARIABLE MACHINE PARAMETERS:
> > think of an volume/pan/frequency...  envelope.
> > it would be fine for the user to add/delete points to the envelope at 
> > runtime.
> > so we need some sort of variable parameter.
> > this is also usefull for a sine-wave-generator with  "over waves" -
> > (sorry my english is not the best, but i guess you now what i mean).
>
> The current plan for OCTAL is to have all envelopes globally shared and
> synch-able; GTK+ already has widgets designed for editing envelopes and
> curves.
>
> > VIRTUAL MACHINES:
> > the user can connect some machines and create a new machine of this
> > set.
> > this virtual machine acts like a normal machine. plus it also can be
> > used in other virtual machines.
>
> Easier said than done, with non-trivial machines; what kind of interface
> does the new "virtual machine" export? That of one machine inside it, or
> all of them stuck together?
>
> There has been some debate here and elsewhere about whether or not this
> "macro" facility is needed in high-level unit generator environments,
> given that each individual machine does so much more by itself. Since
> machines can multi-track dynamically, and since signals can split
> whenever you wish, there isn't as much need to replicate whole identical
> groups of machines (i.e., in old UG systems where each voice of
> polyphony was a replicated set of units.)
>
> In any case, this is probably a GUI issue rather than an internal engine
> issue.
>
> > MIXDOWN MACHINES TRACKS PATTERNS :
> > Softwaresynthesis consumes lots of cpu-power. (i have 166Mhz Pentium).
>
> > To work around these problems we can mixdown tracks, patterns and
> > sequences to waves.
>
> (In buzz this was implemented as a machine; there might not be any need
> to add this to the engine)
>
> This sounds like a nice idea at first but I can't help but point out
> that it will probably not be used too much by people with recent CPU's.
> Plus, since we would now have to store all the recorded sample data from
> patterns/tracks/machines, we now need lots of memory. (OCTAL samples are
> currently 32-bits long) Since now the engine needs to know where the
> pre-recorded material is and whether to play the pre-recorded stuff or
> cause the machine to generate, the engine needs to get a lot more
> complex to do all this caching. And if you run out of memory (not
> unlikely on a slower old machine) then the OS will need to go to disk,
> at which point the entire thing falls apart (especially if you have a
> slow computer, which is why we did this to begin with :-)
>
> I think a better approach would be a hard-disk-recording plugin (which
> can also work from memory) which can play patterns that you've
> pre-recorded (and perhaps edited/effected with a sound editor?). Doing
> automatic, transparent "pre-recording of patterns" isn't interesting
> enough to justify redesigning/complexifying the engine.
>
> > The Sequence Editor:
> > I think of an editor you now from MIDI-sequencers. But instead of this
> > unuseable note editor, we use a tracker interface.
>
> I agree with you; MIDI sequencers are unusable and "blobby." Most of
> them suck.
>
> > This leads me to the idea of using an event triggerd synthesizer. The
> > advantage of this: you can have an midi-interface. But i don't know
> > yet how to realize that.
>
> :-) What besides "events" can trigger a synth..? Well anyway, MIDI
> support will be done with a tracker interface. There's no reason we
> can't have a MIDI-out machine like Buzz does; for MIDI in control, there
> will be inside support in the engine for that kind of input. It'll be
> for realtime control of parameters, and probably also recording of note
> performances and controller-->track pattern conversions. Beyond this,
> OCTAL will not be a MIDI sequencer.
>
> It's a little early to get to that though... I'm still coding the normal
> UG engine and working on the algorithms.
>
> > WIDGETSTYPES:
> > MULTISWITCH: this thing has 2 to n states. each state has a 
> > text-description to know the actual state.
> > Example: Filter: LOW MID HIGH
>
> The newer, revised version of the OCTAL API Developer's Guide (to be
> posted soon) has more details on how OCTAL's API implements choices such
> as this, i.e. named-options exactly as you describe here. You might want
> to check it out once finished (see the OCTAL home page
> http://www.gnu.org/software/octal and there's a link from there) and see
> if the ideas in there match up with what you've been saying.
>
> Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
> :-)
>
> --__--__--
>
> Message: 3
> Date: Thu, 27 Apr 2000 15:00:54 -0400
> From: dave <address@hidden>
> Organization: x
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> > I think a better approach would be a hard-disk-recording plugin (which
> > can also work from memory) which can play patterns that you've
> > pre-recorded (and perhaps edited/effected with a sound editor?). Doing
> > automatic, transparent "pre-recording of patterns" isn't interesting
> > enough to justify redesigning/complexifying the engine.
>
> Just thought of this:
>
> Having an HD/memory recorder module would also allow us to do more than
> just play back pre-recorded synth patterns; we could use live and studio
> material (vox, instrumentalists) inside the tracker, without just
> sampling everything. That means when you press play, the HD-plugin would
> start playing right in the middle of where it's supposed to be, without
> having to wait for a note to trigger the sample (as happens if you try
> to import vox into a tracker now.)
>
> --__--__--
>
> Message: 4
> From: "Danny P." <address@hidden>
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Date: Thu, 27 Apr 2000 16:22:14 EDT
> Reply-To: address@hidden
>
> >Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
>
> language translation? or format?
>
> We need an HTML version more than anything... :)
>
> Dan
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> --__--__--
>
> Message: 5
> Date: Thu, 27 Apr 2000 15:35:21 -0400
> From: "Dave O'Toole" <address@hidden>
> Organization: OCTAL http://www.gnu.org/software/octal
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> "Danny P." wrote:
>
> > language translation? or format?
> >
> > We need an HTML version more than anything... :)
>
> Language. Format translations (i.e. to html) can be done mechanically
> (LaTeX2HTML even renders the figures/maths as little GIFS and auto-links
> everything for you.)
>
> --
> @@@ david o'toole
> @@@ address@hidden
> @@@ www.gnu.org/software/octal
>
> --__--__--
>
> Message: 6
> From: "Danny P." <address@hidden>
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Date: Thu, 27 Apr 2000 18:38:24 EDT
> Reply-To: address@hidden
>
> >Language. Format translations (i.e. to html) can be done mechanically
> >(LaTeX2HTML even renders the figures/maths as little GIFS and auto-links
> >everything for you.)
>
> I'm from montreal. fluent in both english and french...
> Dan
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> --__--__--
>
> Message: 7
> Date: Fri, 28 Apr 2000 00:44:31 +0200
> From: Luka Frelih <address@hidden>
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> > > it would be fine for the user to add/delete points to the envelope at 
> > > runtime.
> > > so we need some sort of variable parameter.
> > > this is also usefull for a sine-wave-generator with  "over waves" -
> > The current plan for OCTAL is to have all envelopes globally shared and
> > synch-able; GTK+ already has widgets designed for editing envelopes and
> > curves.
>
> what's the rate at which these envelopes are reported to the machines?
> do you think users would want to influence this rate somehow?
> maybe set it high just for some machines that need it...
> or is this just tempo*16n?
>
> i guess a way to send these into the system in real-time (==with a constant,
> small latency) would need to exist if we wanted to drive octal with a midi
> controller someday. or from a friendly neighbor process. but the clock issues
> involved are probaly pretty involved...
>
> > > VIRTUAL MACHINES:
> > In any case, this is probably a GUI issue rather than an internal engine
> > issue.
>
> i think i agree - pd has a nice implementation of this concept but its
> building blocks are much more low-level than octals so you need a lot of 
> objects
> a lot of times to do something. so that's why it helps to make higher-level 
> "machines"
> in separate windows which you can close when you're done fiddling with them.
> these machines can have several inputs and several outputs.
> but for octal i'd just recommend that it'd be possible to scroll and  zoom the
> network view - so that the size of our army of synths isnt limited by our 
> small screensize...
>
> of course the possibility of making custom kickass guis for certain parameters
> of great importance in the network from fan-made 32bit skins would well,
> i guess it could impress some people. (me too) david has more important stuff 
> to
> write now but someday, someone with too much time entirely will maybe come by
> and put this in. and then, a day after, someone will make a rebirth from 
> octal... ;)))
>
> > Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
>
> send me the source and i can try to start a slovenian translation
> a friend is just now making a users manual for buzz and i guess
> i can borrow his terms. ;)
>
> L
>
> --__--__--
>
> Message: 8
> From: "=?iso-8859-1?Q?G=FCnter_Seethaler?=" <address@hidden>
> To: <address@hidden>
> Subject: Re: [Octal-dev] suggested features
> Date: Fri, 28 Apr 2000 00:29:39 +0200
> charset="iso-8859-1"
> Reply-To: address@hidden
>
> -----Ursprüngliche Nachricht-----
> Von: Luka Frelih <address@hidden>
> An: address@hidden <address@hidden>
> Datum: Freitag, 28. April 2000 00:44
> Betreff: Re: [Octal-dev] suggested features
>
> >> > it would be fine for the user to add/delete points to the envelope at
> runtime.
> >> > so we need some sort of variable parameter.
> >> > this is also usefull for a sine-wave-generator with  "over waves" -
> >> The current plan for OCTAL is to have all envelopes globally shared and
> >> synch-able; GTK+ already has widgets designed for editing envelopes and
> >> curves.
> >
> >what's the rate at which these envelopes are reported to the machines?
> >do you think users would want to influence this rate somehow?
> >maybe set it high just for some machines that need it...
> >or is this just tempo*16n?
> >
> >i guess a way to send these into the system in real-time (==with a
> constant,
> >small latency) would need to exist if we wanted to drive octal with a midi
> >controller someday. or from a friendly neighbor process. but the clock
> issues
> >involved are probaly pretty involved...
> >
> >> > VIRTUAL MACHINES:
> >> In any case, this is probably a GUI issue rather than an internal engine
> >> issue.
> >
> >i think i agree - pd has a nice implementation of this concept but its
> >building blocks are much more low-level than octals so you need a lot of
> objects
> >a lot of times to do something. so that's why it helps to make higher-level
> "machines"
> >in separate windows which you can close when you're done fiddling with
> them.
> >these machines can have several inputs and several outputs.
> >but for octal i'd just recommend that it'd be possible to scroll and  zoom
> the
> >network view - so that the size of our army of synths isnt limited by our
> small screensize...
> >
> >of course the possibility of making custom kickass guis for certain
> parameters
> >of great importance in the network from fan-made 32bit skins would well,
> >i guess it could impress some people. (me too) david has more important
> stuff to
> >write now but someday, someone with too much time entirely will maybe come
> by
> >and put this in. and then, a day after, someone will make a rebirth from
> octal... ;)))
> >
> >> Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
> >
> >send me the source and i can try to start a slovenian translation
> >a friend is just now making a users manual for buzz and i guess
> >i can borrow his terms. ;)
> >
> >L
> >_____
>
> just coming home now . anyone want come by at irc.linux.com on channel
> #octal. waiting there for a while.
> __________________________________________
> >Octal-dev mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/octal-dev
> >
>
> --__--__--
>
> Message: 9
> Date: Thu, 27 Apr 2000 18:04:44 -0400
> From: "Dave O'Toole" <address@hidden>
> Organization: OCTAL http://www.gnu.org/software/octal
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> > > The current plan for OCTAL is to have all envelopes globally shared and
> > > synch-able; GTK+ already has widgets designed for editing envelopes and
> > > curves.
> >
> > what's the rate at which these envelopes are reported to the machines?
> > do you think users would want to influence this rate somehow?
> > maybe set it high just for some machines that need it...
> > or is this just tempo*16n?
>
> I think you mean "oscillators" not "envelopes." Envelopes, like vol
> envelopes for waves, are not "reported"; they're stored like waves,
> since a given machine may have multiple sounds playing that want to
> follow the envelope, each at a different point in the envelope.
>
> Oscillators (like LFO's) for global sync (not sure how useful it is, but
> some Buzz ppl have suggested it) could be achieved by holding a data
> buffer (equal in size to the block-size being generated at each block of
> time) which is filled with the appropriate data for that block.
>
> Everything--all events and sound generation--everything in OCTAL is tied
> to the block-size. These blocks are small chunks of samples, out of
> which "ticks" are built.
>
> > i guess a way to send these into the system in real-time (==with a constant,
> > small latency) would need to exist if we wanted to drive octal with a midi
> > controller someday. or from a friendly neighbor process. but the clock 
> > issues
> > involved are probaly pretty involved...
>
> If everything snaps to block boundaries, we'll get low latency without
> all the timestamping/recalculation issues.
>
> --
> @@@ david o'toole
> @@@ address@hidden
> @@@ www.gnu.org/software/octal
>
> --__--__--
>
> Message: 10
> From: Rettschlag Dirk <address@hidden>
> To: "'address@hidden'" <address@hidden>
> Subject: Tex/LaTex was: [Octal-dev] suggested features
> Date: Fri, 28 Apr 2000 08:16:47 +0200
> Reply-To: address@hidden
>
> > Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
> > :-)
> >
>         I can try to translate it into german.
>
>         Dex
> > _______________________________________________
> > Octal-dev mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/octal-dev
>
> --__--__--
>
> Message: 11
> Date: Fri, 28 Apr 2000 10:21:11 +0200
> From: Helmut Orian <address@hidden>
> To: address@hidden
> Subject: Re: [Octal-dev] suggested features
> Reply-To: address@hidden
>
> > Anyone up for translations of OCTAL docs? TeX/LaTeX experience a must
> > :-)
>
>   I am familiar with TeX/LaTeX,
>
>   if you send me your source, i will do a german translation for you....
>
>   seraph...
>
> > _______________________________________________
> > Octal-dev mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/octal-dev
>
> --__--__--
>
> _______________________________________________
> Octal-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/octal-dev
>
> End of Octal-dev Digest_______________________________________________
> Octal-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/octal-dev

If you want, i can translate it in french.