Re: [sc-dev] fast forwarding the server

[Richard Wentk <richard@xxxxxxxxx>]

Of course. 

But with a preroll option the user can trade off render time vs musical accuracy to meet the needs of the piece and/or their own patience and/or hardware.

It's better to let the user decide what they want.

Richard

On 6 Jan 2013, at 21:37, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:

> Well, but you cannot currently start calculating sound from any
> position. All synths starts from the beginning.
> Sure, in many cases it will be OK to just start the synth again, even
> if it's not at correct time. For example, a reverb effect synth. But
> in other cases, like some kind of complex LFO, or long-time process,
> the musical result would be totally different.
> 
> On Sun, Jan 6, 2013 at 6:32 PM, Richard Wentk <richard@xxxxxxxxx> wrote:
>> The usual MIDI sequencer hack is to have a parameter called preroll, and to start calculating the sound from the preroll position.
>> 
>> This results in an approximation. But often an approximation is good enough to be useful. (And better, IMO, than a complete redesign of every UGen.)
>> 
>> If you give a user an open choice of preroll time, from the start of a piece to some arbitrary moment before the play position, they can decide for themselves how best to trade off accuracy vs render time.
>> 
>> Richard
>> 
>> On 6 Jan 2013, at 16:17, Hanns Holger Rutz <contact@xxxxxxxx> wrote:
>> 
>>> thanks! of course, the problem lies in the requirement of re-presentation, what if there is a present which can not return? :)
>>> 
>>> best, .h.h.
>>> 
>>> 
>>> On 6 Jan 2013, at 16:47, Lucas Samaruga wrote:
>>> 
>>>> 2013/1/6 Hanns Holger Rutz <contact@xxxxxxxx>
>>>> 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.
>>>> 
>>>> Papers... I like papers. The parametric snapshot is a good idea, I imagine it would imply a redesign of the ugen/graph arch.
>>>> 
>>>> I made some reasoning on what is a material logic/concrete, generator/generated and what's the issue with the representation inside here:
>>>> 
>>>> http://aeslac2011.fing.edu.uy/ProceedingsAESLAC2011.pdf
>>>> 
>>>> in Spanish
>>>> 
>>>> @Jonatan I can translate the main ideas if you like (as part of the discussion we never had), but it differs in some structural aspects to your proposal and I guess would not be easy for us to agree.
>>> 
>>> 
>>> _______________________________________________
>>> 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/