[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] fast forwarding the server



btw there are some ideas about extracting and snapshotting state in my paper "Reproducibility and Random Access in Sound Synthesis" (http://cmr.soc.plym.ac.uk/publications/ICMC2011_Rutz.pdf) -- without changing the UGen interface, you will need heuristics in your client about each ugen, and possibly transform them to capture and recall state.

On 6 Jan 2013, at 14:39, Jonatan Liljedahl wrote:

> 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
> fastforwarding.
> 
> 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
>>> composition.
>>> 
>>> 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/
>>> 
>>> 
>>> 
>>> --
>>> /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/
> 
> 
> 
> -- 
> /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/