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

Re: [sc-dev] fast forwarding the server



Sorry but I don't see how preroll would replace server-side
fast-forwarding or state save/recall. Or do you mean in addition to a
fast-forward functionality?

On Sun, Jan 6, 2013 at 11:24 PM, Richard Wentk <richard@xxxxxxxxx> wrote:
> 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/



-- 
/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/