Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

by Christopher Cherrett

Could the community please review the attribution so we may continue with our journey? This attribution appears on the website, github, README and anywhere else you guys need to see it. OOM2 is developed from the base code of MusE (Muse Sequencer) written by the mighty Werner Schweer, and maintained and modified to the present day, by the current Muse2 maintainer Robert Jonsson and his team. We not only willingly credit Werner for his code, but add our deepest respect and admiration as well. Thanks for all your kind words and support. P.S. Chris Cannam, the offer stands if you would like me to sign over all my copyrighted oom code to you. As you explained open source developers have very little but attribution. Well except those that make big bucks off it. -- Christopher Cherrett ccherrett(a)openoctave.org http://www.openoctave.org

14 years, 5 months

OpenOctaveMidi2 (OOM2) beta release

by alex stone

Deep in the basement of the OpenOctaveProject, the team have been working hard, to bring OpenOctaveMidi into the modern age. From the new interface, to the workflow features, OOM2 is the result of a great deal of hard work, and thought. In our Project journey towards a great Linux Audio pipeline, OOM2 represents the next important step. With the help of our platinum sponsor TSI, we were afforded two full time developers to help with the task of getting to where we are today. We would like to thank TSI for their continued longterm support and encouragement. OOM2 linear Midi and Audio sequencer. We announce the beta release of the 2nd version of the OpenOctaveMidi sequencer, known as OOM2. After a change of codebase, a complete rebuild of the user interface, and the addition of new features and functions, we're proud to present this version as our initial beta release. OOM2 is a linear Midi and Audio sequencer for the Linux operating system in both 32 and 64bit. OOM2 uses the following: * JACK-audio - http://jackaudio.org * JACK-midi - for midi support * DSSI - synth plugins * VST(i) - synth plugins (through DSSI, for the moment. We're more interested in native linuxplugins, so the DSSI-VST implementation may be removed.) * ALSA-midi - for midi support * QT4.6.0 or later (earlier versions may work, but are not tested) You can download OOM2 from our github repository at: git://github.com/ccherrett/oom.git Use the command: git clone git://github.com/ccherrett/oom.git to install the source in an empty directory of your choosing, and follow the build instructions in the Readme file. Please note we're adding new commits each day, and more features are coming very soon, hence the Beta release notice. We hope you enjoy using OOM2, and should you have anything you'd like to report, please send an email to: development(a)openoctave.org We can also be found on irc at #openoctave (freenode) Visit www.openoctave.org to find out more! Alex.

14 years, 5 months

Re: [LAD] [LAU] OpenOctaveMidi2 (OOM2) beta release

by Christopher Cherrett

-------- Original Message -------- Subject: Re: [LAU] [LAD] OpenOctaveMidi2 (OOM2) beta release From: Orcan Ogetbil <oget.fedora(a)gmail.com> To: Paul Davis <paul(a)linuxaudiosystems.com> Cc: LAU Mail List <linux-audio-user(a)lists.linuxaudio.org>, Linux Audio Developers <Linux-audio-dev(a)lists.linuxaudio.org> Date: 01/27/2011 11:26 AM > On Thu, Jan 27, 2011 at 11:08 AM, Paul Davis wrote: >> On Thu, Jan 27, 2011 at 9:39 AM, alex stone wrote: >>> Deep in the basement of the OpenOctaveProject, the team have been >>> working hard, to bring OpenOctaveMidi into the modern age. From the >>> new interface, to the workflow features, OOM2 is the result of a great >>> deal of hard work, and thought. In our Project journey towards a great >>> Linux Audio pipeline, OOM2 represents the next important step. >> I think it would be a little more respectful if you notified this >> crowd precisely which *existing* codebase you "put a blowtorch to". i >> already know the answer, but i think it would better to hear it from >> you guys. altering the indentation and global search-and-replace of >> the project name does not constitute much of a blowtorch. >> > Hi Paul, > > Let me shed some light from the opposite side. > > I was one of the developers of the "existing codebase" [1]. Actually, > I joined the project formally about 3 months ago and I believe I made > a significant contribution in porting it to Qt4. The way I joined to > the project was traditional: sent a couple useful patches so that > people can get to know me, and after a couple rounds I got commit > rights. From my experience with open source projects, this is the way > things evolve. (I sent patches to ardour too in the past, you folks > have been friendly all the time. I am pretty sure same thing would > have happened if I contributed more frequently.) > > OOM folks took a different approach. Originally, we granted them an > SVN branch and we were working under the same umbrella. They put > really hard work in their branch, and I admired most of what they did. > The plan was to merge their new features into the trunk. So we asked > for patches for individual features. This never came from them. > Instead they wanted us to grab everything (or a subset) as is. Our > team did not have the resources to take the diff of each individual > file to filter out each separate feature, and we simply didn't want to > accept *everything* as is. Thus, we proposed them to fork. This is > purely due to differences in the workflow and creativity. Thanks for the clarification. > That said, I believe the original codebase deserved a little more > credit than what is there in the bottom corner of the AUTHORS file. > Moreover, when they forked off, they _kindly_ asked us to not backport > some of the changes they made (mostly appearance related). While I do > not have any intention of using their look, I found this a little odd. > You are borrowing tens of thousands of lines of code from a project, > don't give them credit in your project webpage, and tell them not to > use your little contribution in their original codebase. There is > something morally wrong here. As for not using our look, you are free to the style sheet I created for you but change the colors was all I was asking. You should communicate these things directly to me instead of out here in the lions den :) As for more attribution, what would you like. I have no issues with giving you props where you need it. So what do you need? You know there seems to be this idea that we are coming out there to destroy someones project. You said it yourself that we code fast and hard. The reason for this is that we simply need the software. When we were dealing with Rosegarden Micheal McIntyre could not stop swearing at us so we forked. He felt we were invading and told us he refused to let us take over. Oh well :) You know I never wanted to develop audio software, I have much bigger fish to fry. It is just my wife's pipeline is so big that the current software was caving in. I tried to get help from the coders, but there is never much of that to go around. So I took matters into my own hands. We are not like Ardour asking for money all the time. We are doing this to write music. If people (Chris Cannam) and others feel they need more attribution, then that part is really easy to fix. I suspect there is much more to this puzzle than attribution. I suspect we rocked the boat just a bit too much and too fast. Well..... it is only going to get worse if that is the case. I need much more to finish my project with my wife. We have very big plans. This software is such a little part of our lives, but we do need it. Anyhow. I have been up for days coding and need some sleep. I hope you all enjoy our features. After all they are much better than anything in Linux for orchestral scoring. We really outdid ourselves! :) Enjoy! > Anyhow, I wish them good luck with their project. > > Best, > Orcan > > [1] http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-December/075007… > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-user -- Christopher Cherrett ccherrett(a)openoctave.org http://www.openoctave.org

14 years, 5 months

Re: [LAD] What if a fork is not a fork?

by Jens M Andreasen

On Sat, 2011-01-29 at 15:11 -0500, Raymond Martin wrote: > > To remember: If copyrights were not explicitly and in writing signed > > over to you then they were not. > > > > /j > > The copyright in the license is the credit! These are dire straits. I am afraid your ship is heading towards the cliffs. Read your charts again, carefully, before proceeding. SCO also had some imaginative ideas about copyright. They were wrecked! /j

14 years, 5 months

liblv2-gui, new version coming?

by Michael Bechard

Hi everybody, I'm new to the list. Wassup :) I have a question regarding liblv2-gui. On the site (http://ll-plugins.nongnu.org/liblv2-gui.html) there are warnings all over the place about how the lib is not compatible with rev 3+ of LV2. I searched the archives of this list and Google, but to no avail, so I'm asking: is there a new version of this toolset in the works? One that is fully compatible with the latest version of LV2? I'm enjoying the work that Mr. Luthman has put into this toolset and would like to continue using it for my current project. Thanks, Michael Bechard

14 years, 5 months

jack_snapshot http://tapas.affenbande.org/

by Ralf Mardorf

Oops, is there still a source for jack_snapshot, since I can't get connected to http://tapas.affenbande.org/?!

14 years, 5 months

Fwd: Re: [LAU] OpenOctaveMidi2 (OOM2) beta release

by Thorsten Wilms

Alex, clearly mentioning the project you forked is just good manners of the kind that should be expected among civilized people. Your overreaction to Paul's mail is one hell of an ugly sight. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

14 years, 5 months

[ANN] IR: version 1.2

by Tom Szilagyi

Version 1.2 of IR, an LV2 convolution reverb plugin has just been released. This release is the result of many hours of stress-testing, and corrects some small but unpleasant problems you may have run into while using an earlier version. IR 1.2 is intended to be production quality software you can rely on. Please do upgrade to this version. Changes: * fix ir.ttl typo: "doap:license" instead of "doap:licence" * visual feedback of the progress of resampling operations * resampling operations are interruptible; you can no longer crash the plugin by deleting it while resampling a long impulse file * correct GTK2 version requirement and check it in the Makefile: at least GTK 2.16 is needed Source code is available from the usual webpage: http://factorial.hu/plugins/lv2/ir I wist to thank everyone who provided me with valuable feedback. Have fun, Tom

14 years, 5 months

Re: [LAD] ALSA POLLIN event problems

by Louis Gorenfeld

For some reason, gmail has stopped delivering my LAD messages, so apologies if this reply isn't working correctly... I'm attempting to run, in general, a 128 sample buffer (frames per fragment). There is a lower latency mode though which is 64 samples. I have two fragments. Maybe if I want to do this I should be using three at least or make 128 the minimum. But I'm a little confused at the lack of ins and outs being linked. For a full duplex loop, I'd have to have the input before I can process output for example, so I don't see how that works unless I just ignore input requests from ALSA if I am not yet ready to receive. I'm defining "ready to receive input" as the time after I run my processing loop and then get a POLLOUT request. However, when I ignore POLLINs like this, it seems like ALSA immediately POLLINs again and I wind up with something like 50,000 polling requests handled in a second, which drives the CPU usage through the roof. >the in & out are not linked in any way as far as ALSA is concerned >(even though they may be at the h/w level). >a 64 sample buffer (not period) is very, very small. you need very >tight code and a well configured machine to operate like this. what >period size and/or number of periods are you attempting to use? >> Hey, I've been having a lot of trouble with ALSA and processing input >> in a full duplex loop, and I was wondering if anyone here had any >> insight. I'm using the ALSA poll file descriptor method with the mmap >> routines. Typically, my processing loop is blowing past the poll >> statement with input requests (POLLIN), causing the CPU usage to go >> off the charts as it's basically looping as fast as it can go. >> >> Now, I'm handling the inputs in a way that might not be correct. >> Often, ALSA is saying that the available frames is 1.5 times my buffer >> size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples). >> I only get (begin/commit) input when the buffer size matches or >> exceeds the buffer length I send out to the card (the set buffer >> size), and if it exceeds that, I only pick up (commit) one buffer's >> length of frames. Is this wrong? If there is more input waiting, >> does ALSA immediately go and POLLIN again, or should I expect it to >> not bug me again until I've processed a POLLOUT event (the in and out >> are linked)? I'm not really sure how to handle this..

14 years, 5 months

[ANN] csound 5.13 release

by Victor Lazzarini

Basically a bug fixing release but with a number of new opcodes etc http://souceforge.net/projects/csound ==John ffitch Notes for 5.13 ============== New Opcodes: farey sequence opcodes median opcode filevalid opcode Real random number generators using /dev/random (Linux only) pvstanal opcode -- phase vocoder analysis by reading function tables mincer opcode -- Phase-locked vocoder processing temposcal opcode -- Phase-locked vocoder processing with onset detection/processing pvswarp opcode -- Warp the spectral envelope of a PVS signal pvslock opcode -- Frequency lock an input fsig New Gen and Macros: INF macro added to orchestras; z read as infinity in scores GEN for support of farey sequences Modified Opcodes and Gens: init changed to allow multiple inits in on statement maxalloc, cpuperc, instcount now accept named instruments If normalisation in pow opcodes is zero treat as 1 inch can take upto 20 inputs and outputs pvscale and pvsmix now have very good spectral envelope preservation modes (1 = filtered cepstrum, 2 = true envelope). oscil1 could be static if the duration was long; now there is a positive minimum increment. GEN49 now uses search paths pvsvoc enhanced with new spectral envelope preservation code. Bugs fixed: Count of lines fixed in orchestras, and \ inside strings Fast tab opcodes made safe from crashes % in formated printing could crash Double free in fgen fixed sndwarp quietened (gave too many messages) gen41 deals with positive probabilities adsynt reworked removing many bugs adsynt2 phase error fixed atonex/tonex did wrong operation Bug in max number of gens fixed mp3in could repeat sound at end of file Better checking in grain4 modulus was wrong in new parser Better checking in adsyn changed opcode initialised to zero Serious bug in tabmorphia fixed GEN49 has serious bug removed, so no longer incorrect silences. Partikkel opcode: fixed bug in sub-sample grain placement when using grain rate FM nchnls_i working correctly System Changes: In the new parser only there are operator @ and @@ to round up the next integer to a power of 2 or powerof2+1 Score sorting made much faster lineto improved Named gens allowed Various printing include instrument name if available Command option to omit loading a library Number of out channels no longer constrained to be number of in Many fixes to new parser More use of Warnings than Messages (allows for them to be switched off) API: csoundSetMessageCallback reset if callback set to null Internal: usual collection of gratuitous minor changes, layout and comments

14 years, 5 months

Jump to page:

2025

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