[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] fast forwarding the server
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.
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.
>> 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:
>>>> 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/
> 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