Linux-audio-dev January 2011

linux-audio-dev@lists.linuxaudio.org

66 participants
37 discussions

Fwd: Devs needed for opensource virtual analog softsynth idea

by Sascha Schneider

Alsa Modular, is this one still under development?? I never have tested it and never saw a UI that I could use to controll it with external USB controllers. I'll check that .... regards, saschas 2011/1/2 Julien Claassen <julien(a)c-lab.de>: > Hello Sascha! > I'm not good at coding at all, but I think a more useable framework for a > softsynth, if you like to build it with an existing one, might be bristol. > Bristol is a synth emulator. It has a couple of synths already. But it might > not suffer, having a new filter or different oscillator in it, if Nick is OK > with that. The synths it emulates, are basically built from the components > (filters, oscs, etc.), that are in the engine. Then they are connected in a > particular way and get a GUI/CLI put on top of them. Bristol has, what I > would call MIDI learning. You can easily assing MIDI controls to controls of > the currently loaded synth and I think you can save them as well. Have a > look at his site: > http://bristol.sf.net > The sweet thing about using this would be, that you have to implement the > new components and then there is an API - so I believe - for relatively > easily constructing the connections and the <UIs. I know only of the textUI, > which is very clever and helpful! > Kindly yours > julien > > -------- > Music was my first love and it will be my last (John Miles) > > ======== FIND MY WEB-PROJECT AT: ======== > http://ltsb.sourceforge.net > the Linux TextBased Studio guide > ======= AND MY PERSONAL PAGES AT: ======= > http://www.juliencoder.de >

13 years, 3 months

pd-l2ork 20110105 snapshot now available

by Ivica Ico Bukvic

Please pardon cross-posting. Changelog: *fixed segfault when doing to-front/back without any object being selected *added enabling/disabling menu options when appropriate (e.g. cannot cut/paste if nothing is selected) *bound relevant canvas actions to the menu actions so that they can be invoked only if the menu actions are enabled (e.g. cut/copy/paste etc.) *requires further testing *relevant menu options reflect changes across all Pd windows (e.g. duplicate) *added special behavior for the cut/copy/paste menu in the root window *added previous window to the Window menu Latest snapshot is available from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Complete changelog since 11/25/2010 is available here: http://l2ork.music.vt.edu/data/pd/Changelog Best wishes, Ico

13 years, 3 months

usb tools ?

by Dave Phillips

Greetings, A fellow Fender Mustang 1 user is working on native Linux software that can be used with the amplifier. Apparently he needs some tools like usbsnoop to find out what's happening to & from the amp's USB port. He wrote that usbsnoop and snoopyusb weren't able to do the job, so I thought I'd ask if there are other similar tools that might be more up-to-date. Suggestions ? Best, dp

13 years, 3 months

Time-Stretch

by Harry Van Haaren

Hey all, I'm looking for an open-source time-stretching library, suitable for RT work. I've googled and come up with the following list, which I can't choose from: -Soundtouch : http://www.surina.net/soundtouch/index.html -ClearScale / DspDimension: http://www.clearscale.org/ -SecretRabbitCode / libsamplerate : http://www.mega-nerd.com/SRC/ -LibResample : https://ccrma.stanford.edu/~jos/resample/ -MFFM timescale: http://mffmtimescale.sourceforge.net/ -LibZita-Resampler: http://www.kokkinizita.net/linuxaudio/zita-resampler/resampler.html I'm attepmting to write a sample player, that will time-stretch long loops to stay in sync with JACK transport. I've deduced this is what I need to do: - Calculate the amount of samples I need to change the buffer length by - Take the buffer, resample it to a larger / smaller amount of samples. - Playback the samples as I normally would, except that there's more, and hence the audio will stay in sync. Design choices: 1. should I re-sample the whole buffer, and then playback from that buffer? this approach might cause a lot of CPU strain once the rate changes, as the *whole* buffer would be re-sampled at the same time. Once done, the CPU has no strain from resampling. 2. Resample "nframes" amount of samples from the buffer, and play them back? Less sudden CPU overhead, more constant CPU usage. The other problem I'm faced with is that some libraries mention that they do *not* support "dynamically variable resampling ratios". Would I need this? I think I do, as to get the beat "on-time" sometimes I'd need to add 200 samples, while in other cases 210 samples might suit better... I'm aware that Ardour uses SoundTouch, but I'm not sure is that the best lib for real-time use. Mixxx is using LibSamplerate AFAIK, and does so quite well, but might not be as suitable as Soundtouch.. http://www.surina.net/soundtouch/faq.html#sample_processing These kind of paragraphs are what stop me from just choosing one and going with it... Choices, Advice, Laughter, Help, etc all welcome! :-) Cheers, -Harry

13 years, 3 months

On the last eve of the year

by Jens M Andreasen

It was so terribly cold. Snow was falling, and it was almost dark. Evening came on, the last evening of the year. In the cold and gloom a poor little girl, bareheaded and barefoot, was walking through the streets. Of course when she had left her house she'd had slippers on, but what good had they been? ... The Little Match Girl http://mx44.linux.dk/~jens/unpublished/mtchgirl.mp3 ... "She wanted to warm herself," the people said. No one imagined what beautiful things she had seen, and how happily she had gone with her old grandmother into the bright New Year.

13 years, 3 months

PD L2Ork 20101229 snapshot now available

by Ivica Ico Bukvic

Please excuse cross-posting. Dear friends and fellow FOSS enthusiasts, It is my great pleasure to share with the community a belated Holiday present :-) in a form of latest snapshot of L2Ork iteration of Pure-Data. Better than ever, the latest version comes with the following improvements: *implemented apply undo for array properties and partially implemented apply undo for graph-on-parent object properties (does not apply to abstractions or top-level windows currently until I figure out how to address the indexing of toplevel windows inside the glist as well as how to address to which window such an undo belongs). *properties are disabled when right-clicking on an abstraction as modifying its settings externally does not make sense when one does not see the actual contents inside it. So, to edit the properties of an abstraction, one has to open the actual abstraction. *fixed how new arrays are created so that they always fit within the specified boundaries. Please note arrays that have been already created in prior patches remain untouched in terms of graph auto-resizing (legacy code is provided in g_editor.c canvas_vis that deals with this if anyone wishes to convert their arrays but is incomplete in that it assumes all arrays require resizing--this is however unnecessary as simple recreation of said arrays or manual readjustment of their settings ought to do the trick. -This feature needs further testing--feedback is most appreciated. *fixed how arrays deal with moving array points via mouse by restricting them within the array bounds--this should work for all gui-driven array operations, while array alterations via snapshots and other external ways of manipulating arrays remain unbound so as to allow for traditional data-flow debugging--this may change down the road in part due to introduction of the magicGlass option and in part due to belief that data monitoring should only report ranges specified by the graph. -This feature needs further testing--feedback is most appreciated. *added new feature for arrays where they report a bang through the <arrayname>_changed send (if one is provided) whenever they have been altered by a mouse click'n'drag--this in conjunction with array graph auto-resizing makes arrays formidable alternatives for multisliders. -This feature needs further testing--feedback is most appreciated. *when an array subpatch is opened and resized, the array automatically now resizes to properly fill the window. -This feature needs further testing--feedback is most appreciated. *fixed where array was not visible after reopening the patch if any of its points touched upon y graph limits. *fixed couple of segfaults caused by gridflow incompatibility--more problems remain with gridflow library compatibility, likely due to widgetbehavior and possibly also magicGlass incompatibility. Further investigation is necessary. *fixed memory leak in the disis_phasor~ external where the destructor was never properly called and updated its documentation (available in the l2ork_addons package). *fixed highlighting of signal nlets where nlet would revert to non-signal appearance after being highlighted/connected. *reintroduced array listview (this was a regression in respect to pd-extended). *improved appearance of the array listview. *fixed a few broken links in the pddp documentation and added new l2ork-specific array features to the pddp documentation. Latest snapshot is available from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Complete changelog since 11/25/2010 is available here: http://l2ork.music.vt.edu/data/pd/Changelog Happy belated Holidays! Best wishes, Ico

13 years, 3 months

Fwd: Devs needed for opensource virtual analog softsynth idea

by Sascha Schneider

I love attractive UIs like those from Bristol, have to try those ... I want to use them in f.e. Qtractor or Rosegarden as softsynths with some live character with external midi-controllers or with automation. regards, saschas 2011/1/2 Ricardo Wurmus <ricardo.wurmus(a)gmail.com>: > Hi Sascha, > > I found the AlsaModularSynth to be a great sounding "analog-ish" modular > synthesizer with a very direct and very usable interface. > > I don't quite understand your vision just yet. Is the idea basically to > write an attractive and usable GUI for an existing synth (engine)? > > > > On 2 January 2011 21:47, Julien Claassen <julien(a)c-lab.de> wrote: >> >> Hello Sascha! >> I'm not good at coding at all, but I think a more useable framework for a >> softsynth, if you like to build it with an existing one, might be bristol. >> Bristol is a synth emulator. It has a couple of synths already. But it might >> not suffer, having a new filter or different oscillator in it, if Nick is OK >> with that. The synths it emulates, are basically built from the components >> (filters, oscs, etc.), that are in the engine. Then they are connected in a >> particular way and get a GUI/CLI put on top of them. Bristol has, what I >> would call MIDI learning. You can easily assing MIDI controls to controls of >> the currently loaded synth and I think you can save them as well. Have a >> look at his site: >> http://bristol.sf.net >> The sweet thing about using this would be, that you have to implement the >> new components and then there is an API - so I believe - for relatively >> easily constructing the connections and the <UIs. I know only of the textUI, >> which is very clever and helpful! >> Kindly yours >> julien >> >> -------- >> Music was my first love and it will be my last (John Miles) >> >> ======== FIND MY WEB-PROJECT AT: ======== >> http://ltsb.sourceforge.net >> the Linux TextBased Studio guide >> ======= AND MY PERSONAL PAGES AT: ======= >> http://www.juliencoder.de >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev > >

13 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev January 2011