Multi-rate handling is not an easy problem. The current explored model is to work on a lower-level « on demand » primitive, see:
https://github.com/orlarey/faust-ondemand-spec/blob/newmaster/spec.pdf Stéphane > Le 23 févr. 2022 à 12:11, Roman Sommer <ro...@resonant-bytes.de> a écrit : > > Hi Stéphane, > > Thanks for your reply! Good luck/success with your application! > > I had a skim over the list and nothing immediately caught my interest > which wasn't already picked up. > There seem to be several web-related topics, which I would prefer to > avoid. I'm more of a low-level, systems person ;) > > Concerning my own ideas: > One thing I have wished for in Faust for a long time is actually support > for multiple sample rates. > I realize this is probably a huge undertaking as otherwise you would > probably have already done it. > > In the following I describe my outside view on the issue. Please feel > free to correct me or point me in a direction where problems which I > have overlooked have been discussed. :) > > In my imagination, (without knowing any Faust internals) it > should in principle be possible to annotate functions so they run at a > fixed rate or a rational multiple p of the system rate. > As long as the buffer size can be evenly divided by the denominator of > p, an input buffer with n samples can be resampled into a buffer with > m = n * p samples before executing that function and the graph can > continue to be executed from there with the changed sample-rate. > Any reference to the system rate would have to be shadowed by the new > value. > That would allow arbitrary upsampling and consecutive downsampling by > the same factor, as well as downsampling depending on the buffer size. > Assuming buffer sizes are usually powers of two, the range for that is > probably at least 2-32. > > Thank you again very much! > > > Cheers, Roman > > Stéphane Letz <l...@grame.fr> writes: > >> Hi Roman, >> >> Thanks for your interest in Faust and its ecosystem. >> >> We are working on our GSoC Organization questionnaire hoping we’ll be >> accepted this year. >> >> We also have a « faustideas » GitHub project >> https://github.com/grame-cncm/faustideas) where we collect some ideas on >> developments to be done. Note that the list is somewhat old and we plan to >> refresh and complete it soon to better fit the GSoC requirements. >> >> Fee free to suggest ideas you already have that could complete this list. >> >> Stéphane >> >>> Le 19 févr. 2022 à 15:41, Roman Sommer <li...@resonant-bytes.de> a écrit : >>> >>> >>> Hi there, >>> >>> I wrote a similar mail to the LAD list a few days ago where I received the >>> suggestion to write to you, the FAUST project, directly (among others). >>> My name is Roman, I'm studying Computer Science and I'd like to participate >>> in the GSoC this year. >>> Also I'd like to do this in a linux audio related project if possible, >>> because I want to help improve the Linux Audio world! >>> That's why I'm asking you if you, if you plan to participate in the GSoC as >>> an organisation this year and would be interested to think about and >>> discuss project ideas together. :) >>> >>> My background: >>> I'm a Master student in CS and my focus so far has been centered around >>> operating systems (incl. kernel development), security, >>> concurrency and (hard) real-time. >>> At the University I also took a few signals, systems and DSP courses, so I >>> know what an LTI system is, how digital filters work >>> and what a hilbert transform does. >>> To pay my rent and food I work part time as a repair technician fur >>> electronic musical instruments and equipment and therefore >>> have a background in electronics as well. >>> I'm also a passionate hobby musician and live mixing technician. >>> >>> I know how to write C code that doesn't blow up. I'm familiar enough with >>> C++ to get around comfortably. >>> Recently I started writing an 8-bit microcontroller emulator as a >>> University project in Rust and so far I really like the >>> language. >>> Python is also a very nice language in my opinion. >>> Audio related things I've written include python bindings for the jack dbus >>> interface [0], a jack application managing tool to start/stop/mute >>> applications via hardware buttons and used mididings to map MIDI CC to >>> Sysex for my hardware synths [1]. >>> I've also written a bit of FAUST code to create a number of effects I want >>> to use. >>> >>> A few ideas and fields I can imagine working on (non-exhaustive, no >>> particular order): >>> - Emulation of analog hardware (setBfree still needs a nice overdrive afaik >>> ;) ) >>> - multi-rate processing for non-linear systems >>> - Polyrhythmic sequencing >>> - Sysex integration in sequencers >>> - Linux kernel work >>> - jack and/or pipewire >>> >>> Something I'd really like to see someday is being able to sit down at (or >>> stand up with) my Instrument and just jam and when I >>> played something I like, I can go back to, say, 28s ago and extract a few >>> bars and build a song from there. >>> >>> Also I'd really like to hear your ideas and suggestions! :) >>> >>> I'm really looking forward to your responses and hopefully a great >>> collaboration as a result! >>> Feel free to ask any questions, as will I! ;) >>> >>> Cheers, >>> >>> Roman / etXzat >>> >>> [0] https://github.com/romsom/midiutil >>> [1] https://github.com/romsom/python-jackdbus >>> >>> >>> _______________________________________________ >>> Faudiostream-devel mailing list >>> Faudiostream-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel _______________________________________________ Faudiostream-devel mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
