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

Re: [sc-dev] fast forwarding the server



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/