[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] fast forwarding the server
- To: sc-dev@xxxxxxxxxxxxxxxx
- Subject: Re: [sc-dev] fast forwarding the server
- From: Hanns Holger Rutz <contact@xxxxxxxx>
- Date: Sun, 6 Jan 2013 14:13:16 +0100
- In-reply-to: <CAFu0fFdCehANWuh00UnY6WUCaqEg7vdeDehbKwq75kHH-ND=zA@mail.gmail.com>
- List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
- References: <CALfiFhB5hNOA7+vDtct-cvcrPKC-MwmBQZNkM_fX99VE7L8wdA@mail.gmail.com> <A87E87D0-F972-4E2F-B1DB-8F5DE6EB59D9@sciss.de> <CALfiFhDPMHNkmgCUHEdmAamXKLUStL3+puQ0QdpBMpGp7HrCOw@mail.gmail.com> <CAFu0fFdCehANWuh00UnY6WUCaqEg7vdeDehbKwq75kHH-ND=zA@mail.gmail.com>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
if you don't depend on realtime input, i see no problem forwarding the server by letting it calculate as fast as possible... this is _not_ random access yet. of course, with a DAW or something like algoscore you could say the client can do a random seek, but you would still have problems with for example long running synths that depend on initial random seed or chaotic oscillators, or perhaps warming up a long reverb tail. in those cases, the fast-forward makes sense, because you might not want to produce large pre-rendered files. (besides... that's not possible as NRT still doesn't have an OSC interface yet).
On 6 Jan 2013, at 13:54, Lucas Samaruga wrote:
> The only sound one can play at random without loosing information is a rendered sound file (or a synced set of they as in a daw), events are incomplete as audio information in many cases. Why not just to provide a clear interface to render offline with one server while processing rt and playing in other server with the current approach? Just to access a daw looks like the clearest approach to me.
> El dic 20, 2012 7:58 p.m., "Jonatan Liljedahl" <lijon@xxxxxxxxxxxx> escribió:
> Ah, of course! Yes, switching to/from this new NRT mode would be
> fantastic, when dealing with DAW-like time based interfaces for
> On Thu, Dec 20, 2012 at 11:35 PM, Hanns Holger Rutz <contact@xxxxxxxx> wrote:
> > https://github.com/supercollider/supercollider/issues/279
> > http://article.gmane.org/gmane.comp.audio.supercollider.devel/27755
> > http://article.gmane.org/gmane.comp.audio.supercollider.devel/27757
> > http://article.gmane.org/gmane.comp.audio.supercollider.devel/27758
> > essentially what you are proposing is this new NRT mode brought forward at various occasions (including your own comments :) ... only that now you would even be able to switch a realtime running scsynth to this NRT mode.
> > +10000000 from me. i would love this!!
> > best, .h.h.
> > On 20 Dec 2012, at 23:22, Jonatan Liljedahl wrote:
> >> While dreaming about a graphical timeline score editor (algoSCore), I
> >> thought about the possibility to fast forward the server.
> >> It would be a server command, taking a time amount argument. When
> >> getting this message, the server runs through all samples, while
> >> muting the audio outputs, as fast as possible until the time has
> >> reached NOW + the amount given in the argument. Kind of like switching
> >> to NRT mode for a while.
> >> For example, one might have an EnvGen or Line running several minutes
> >> in your piece, and you want to hear it from the middle.
> >> Just skipping time would not work, since all samples would need to be
> >> calculated to know that you get the exact same result as you should at
> >> that point in time.
> >> Thoughts? Would it be doable?
> >> --
> >> /Jonatan
> >> http://kymatica.com
> >> _______________________________________________
> >> sc-dev mailing list
> >> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> >> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> >> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
> > _______________________________________________
> > sc-dev mailing list
> > info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> > archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> > search: https://listarc.bham.ac.uk/lists/sc-dev/search/
> sc-dev mailing list
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml