Re: [LAD] Program design: C++ - SHM - Python
On Sunday 26 December 2010 02:05:03 Harry Van Haaren wrote: Hi, I've been trying to come up with a nice program architecture for a live performance tool (Audio looping etc), and I've kind of hit a wall: Input will be taken via OSC, the engine will be written in C++, and the GUI is up in the air. I've written most of the engine, (working to a degree needs some bugfixes), and now I've started implementing the GUI in the same binary. Ie: its all compiled together, double-click it and it shows on screen loads JACK client. The GUI code has a nasty habit of segfaulting.. which is also killing the engine. That's a no-go for live performance. The engine is rock solid stable. So its the fact that there's the GUI thread running around that's segfault-ing things. So I'm wondering if it feasible to keep the audio/other data in SHared Memory, and then write the GUI in Python reading from the same memory? Is this concidered ugly design? I have no experience with SHM, so I thought I'd ask. The other option I was concidering is writing the front-end GUI part using only info obtained from OSC, but that would exclude the waveforms of the audio, and lots of other nice features... You could do both: Connect the gui via OSC for general usage and define a shared memory for the big-data for local usage. If your engine is that rock- stable, you might want to run it on a headless machine and control it via OSC. Which allows the gui to run on any win/linux/mac/ipad/ipod/galaxy tab/whatever. And once the shmem is working, you can try to port some of that to osc too. Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Program design: C++ - SHM - Python
On Sun, Dec 26, 2010 at 10:56:59AM +, Harry Van Haaren wrote: Summing up: Large data ( ±384,000 samples of float type ) OK to send with OSC? Depends entirely on if the delay is acceptable or not. You can send it as a binary blob - encoding each sample would be quite a waste of time. Ciao, -- FA There are three of them, and Alleline. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Program design: C++ - SHM - Python
On Sun, Dec 26, 2010 at 11:20 AM, f...@kokkinizita.net wrote: Depends entirely on if the delay is acceptable or not. You can send it as a binary blob - encoding each sample would be quite a waste of time. I should have specified: The data will be the Sample played back by the engine, and it will be sent to the GUI, to be able to show the waveform / spectral etc info. IMO: Delay acceptable yes. Binary blob is good advice, thanks. Ill try it out when I get some time, and will report back. -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Program design: C++ - SHM - Python
On Sun, Dec 26, 2010 at 12:37:47PM +, Harry Van Haaren wrote: On Sun, Dec 26, 2010 at 11:20 AM, f...@kokkinizita.net wrote: Depends entirely on if the delay is acceptable or not. You can send it as a binary blob - encoding each sample would be quite a waste of time. I should have specified: The data will be the Sample played back by the engine, and it will be sent to the GUI, to be able to show the waveform / spectral etc info. IMO: Delay acceptable yes. Binary blob is good advice, thanks. One thing to consider: sending such large blocks of data may block the sender, so you should not do this from the RT audio processing thread. Ciao, -- FA There are three of them, and Alleline. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Program design: C++ - SHM - Python
On Sunday 26 December 2010 14:02:49 f...@kokkinizita.net wrote: On Sun, Dec 26, 2010 at 12:37:47PM +, Harry Van Haaren wrote: On Sun, Dec 26, 2010 at 11:20 AM, f...@kokkinizita.net wrote: Depends entirely on if the delay is acceptable or not. You can send it as a binary blob - encoding each sample would be quite a waste of time. I should have specified: The data will be the Sample played back by the engine, and it will be sent to the GUI, to be able to show the waveform / spectral etc info. IMO: Delay acceptable yes. Binary blob is good advice, thanks. One thing to consider: sending such large blocks of data may block the sender, so you should not do this from the RT audio processing thread. Another thing: OSC is generally sent per udp. The bigger the datagram, the less likely it is actually sent and received. If you encounter this, either split the data into smaller chunks to be sent or use the osc to define a tcp- connection for the big binary data. Include avahi/bonjour/zeroconf into your equation and it will be the cure for cancer or something equally cool. Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] on the soft synth midi jitters
Does anyone have any experience with speed of traversal through a boost multi index container? I'm pondering their use to manage notes currently in play, eg indexed by midi channel ordered by midi event time/frame stamp. cheers, Cal ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] seeking fresh way to process/shape human whisper in real-time
On Fri, Dec 24, 2010 at 11:43 AM, i...@vt.edu wrote: Quoting Loki Davison loki.davi...@gmail.com: Mod it with a string instrument is my preference. I know i'm a bit too keen on acoustic instruments now days but it would be very neat to have a cello or double bass, etc as the control source to be filtered/modulate in with the whispers or each other. Guitar or bass with an ebow would also work. Reso's are great for that. Loki Many thanks for the suggestion Loki. Do you mind elaborating however? I am not sure what kind of modulation you are suggesting. Also, by reso, do you mean resonant filter? Many thanks! Sorry for the slow reply, busy period! I'm suggesting you use the string instrument as the controller of the whisper source/oscillator. So in the basic case the volume of the string instrument controls the volume of the whisper. You can then extend it so the other parameters of the string instrument such as the frequency control something else like the delay, spatial location or some filtering. Layering this could sound quite interesting and you could combine layers of strings and whispers controlled by strings. Sorry for the ambiguous wording; by reso i was referring to a resonator guitar, a type of guitar that works very well with an EBow and thus would be quite cool for this use. Resonator guitars are made out of metal, I use this rather lovely sounding gold tone, Paul Beard Signature: http://www.goldtone.com/products/enlarge.asp?view=545 Loki ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
