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

Re: [sc-dev] fast forwarding the server



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/