[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] fast forwarding the server
- To: "sc-dev@xxxxxxxxxxxxxxxx" <sc-dev@xxxxxxxxxxxxxxxx>
- Subject: Re: [sc-dev] fast forwarding the server
- From: Jonatan Liljedahl <lijon@xxxxxxxxxxxx>
- Date: Sun, 6 Jan 2013 14:39:43 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=r3dn5KAMfj9NMSoSgryNG8CrYeZjy8kg01iwwyp555E=; b=zZwWcsoZmf1hvcXEdE40lLi6p3fXT/c6hB49jbeHSqu3QFuqS5ZJmfTj+CXG0R3KgM vJ/JJ9V3AXzFik2MeyFdsX63g1uiCjUz4alSWryFaOV/TAk5jSEaWSa7n4XYxWLMy83z 8USCd+Gwr8x+fPigbCKKa7fuyT/IkZXwoh6trzIWAXXYywL8gWSWlyG+RF4nqtQpHUta PmYeWOVFR6PsmSvuJVegGeHHZIPmeu0j7ScZIo1cSFWw85eD0syuO4HyN11iHLuy8ecj tyv3sFX5F9EefxoLt1FOqjFlxWX1Vl/JvFoTin2utFWcFyJ5DT/EjnerY9pHA4s2tiMi 25iQ==
- In-reply-to: <CA2C3A7B-0675-4AB3-93C6-E6C3E687E4DA@sciss.de>
- 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> <CA2C3A7B-0675-4AB3-93C6-E6C3E687E4DA@sciss.de>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
Yes, exactly. I'm not hoping for real random access, but to for the
user of algoscore it should look like that. You put the play cursor
somewhere and you can play from there. It would probably involve a
dialog popup that says "locating..." or something.
The bad thing is of course that this will take longer time at the end
of the piece, and might take *very* long time if the music is
complex.. But, this would only need to be done from the point of
earliest start of currently running synths, so one can have sections
of music and only need to fastforward from the start of the section,
not the entire piece.
Another thought: the only reason to fastforward like this is to get to
a particular state. This state itself is quite lightweight, just a
bunch of variables. What if we could save and recall these states? For
example, save the state everytime the user plays from a new position,
meaning it will be instant to play from that place again. And/or save
state once per second, or ten seconds. Then it's only a couple of
seconds that needs to be fast-forwarded.
Note that this is all server-side. Language-side, one would need to
implement something similar for each kind of technique used. For
example, fastforwarding a pattern should not be hard. In an
environment like my coming algoscore, one might have
break-point/envelope curves built-in that implements such
On Sun, Jan 6, 2013 at 2:13 PM, Hanns Holger Rutz <contact@xxxxxxxx> wrote:
> 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).
> best, .h.h.
> 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
> 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