From: Juhana S. <ko...@ni...> - 2006-08-04 09:55:46
|
>From: Rados.aw Korzeniewski <rad...@ko...> > [ ... ] You listed so many items that perhaps we should look if there is some other editor which already have most of the features, and then all we should join that project. ;-) Could Ardour be modified to include Sweep-type application? Audacity is already excellent but has annoying features as well. >- waveform scrolling when playing (now its jump page by page) (ID: 712020) >- display-cache for speeding-up drawing The overview files would help too. Do we have them? Generating them also offline, e.g., with "sndfile-overview", would be very nice. The cache should be large enough so that user may switch between the window and the fullscreen modes without redrawing. Scrubbing needs extra cache too if user may grab the waveform and move it (instead of moving the cursor). >- audio preview while browsing audio files (ID:637291) Display preview? Then overview files would help. Audio preview would be nice too. >- batch (macro?) processing of sound data (ID:654580) Swig interface would be good. Swig would offer support for many scripting languages in one go. Scripting would allow easy addition of new features. Script file directory + script menu or browser. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software |
From: Heimo C. <ha...@re...> - 2006-08-17 23:01:37
|
<besides> what's "trac" and a "trac ticket" ? </besides> Talking priorities: The real thing is still memory handling; and there it's obviously waiting for Conrad... I'd like to use Sweep for montage/editing of longer pieces (which doesn't work yet, see above - an half-hour feature has it crashing) and that would need some least kind of timeline or other visual listing of clips and files (if not to speak of a "filebank".) And finally, stubbornly, I longue for a user-friendly way to (re-)arrange hotkey bindings. Some of the present ones are definitively _not_ legitimated by referencing to an idiot "other" prog. (Anyone ever heard about ergonomy, RIS and the like ?) -hc |
From: peter <zen...@ze...> - 2006-08-18 14:56:10
|
On Fri, 2006-08-18 at 00:02 +0100, Heimo Claasen wrote: > <besides> what's "trac" and a "trac ticket" ? </besides> see trac.metadecks.org trac is a web based developers tool that provides a timeline of various changes, a roadmap (which isn't effectively used yet) a ticket system (bugs, feature requests and comments) and interacts closely with a subversion repository (providing a diff like view of commits and displays the files contained there) oh, and a simple wiki. it was also reamed by spammers and so now you need to authenticate before you can edit anything. i can make accounts for anyone interested but they are not necessary if you just want to submit bug reports (email or the lists are fine for that) basically our trac and svn repository replace sourceforge as a base for sweep. > Talking priorities: > The real thing is still memory handling; and there it's obviously waiting > for Conrad... ..and his remix library, which will not be incorporated until 1.0 has been released. i have fixed a few memory related bugs but redesigning sweeps memory handling system is both beyond me and pointless when libremix is on the horizon. > I'd like to use Sweep for montage/editing of longer pieces (which > doesn't work yet, see above - an half-hour feature has it crashing) got a bug report? these really do help even if the problem is already known. > and that would need some least kind of timeline or other visual > listing of clips and files (if not to speak of a "filebank".) a timeline? sounds like a multitrack editor. which sweep isn't. (although it might eventually become that). otherwise, i'm not sure what you mean by that. in terms of fighting with multiple open windows, i want to add a list of open files and plugin dialogs somewhere along with the plugin browser that i'm working on now (..and again ;) sample displays and plugin dialogs would be either be shown in a separate window (as they are now) or displayed in one window in tabs. (with the actual notebook tabs hidden) the list allowing you to quickly switch between one or the other (where you can toggle the state of any one (tabbed or a window) in the list) Radoslaw is working on a navigation bar that should make editing large files much much easier too. :) > And finally, stubbornly, I longue for a user-friendly way to (re-)arrange > hotkey bindings. Some of the present ones are definitively _not_ > legitimated by referencing to an idiot "other" prog. > (Anyone ever heard about ergonomy, RIS and the like ?) as i think i said before, in for 0.9.3 at the latest. you can check the work in progress branch here: svn co http://svn.metadecks.org/sweep/branches/sweep-ui-manager cd sweep sweep-ui-manager ./autogen.sh ./configure make make install /usr/local/bin/sweep (be aware that "make install" will overwrite any preexisting sweep installation in /usr/local but this step is necessary as the icons are now PNGs and need to be installed) it builds and runs but it's not completed yet and so isn't useful for actual editing yet. note, you may need to enable accel editing in gnome (via gconf-editor) left to do: use GtkAction callbacks instead of existing callbacks (partly done) rework icons with a fixed geometry. (gtk resizes the icons to a common size and this looks a bit fuzgly) save and restore edited accels add some code to link the nonstandard transport bar widgets to GtkUIManager something else that i forgot. sadly, all of these are easy. uhm.. i mean happily. cheers, pete. |
From: Heimo C. <ha...@re...> - 2006-08-24 02:24:07
|
Thanks, Pete, for the "trac/-ticket" enlightenment; a shorter while off the track seems enough to get out of the window of terminology (and I hadn't followed Sweep's development so closely, indeed waiting for signs of a solution for the - for me - determining solution of memory handling.) A good time ago, around Sweep-0.8.0x, I trampled on Conrad's nerves with the mem thing; maybe it stimulated his thinking nevertheless. There isn't much more of a bug report to do on it: simply load a numbwer of files and Sweep will crash with the "one more drop". [Despite reasonable RAM installed - 784K was that in 2003/04 - the crash reproduced reliably after the n+1.st additional file opened from a same series of some 20 WAVs, and strictly in function of the total volume opened; I did a lengthy series of variations. There was an interesting sub-observation [subservation?] of kind of a "socket" of live mem occupation around <400KB where first additions didn't change total mem use, but further added files immediately added through until "mem full". I had sent all this to Conrad at the time.] Obviously I used the word "timeline" ambiguously[*] (taking it from traditional cutting/scripting language) - I wouldn't mean "multitracking" at all, and maybe your "file browser" is already on a good way towards it: With cutting/pasting/montage one needs kind of an overview where the various bits are in the "base file", or are stored, which make part of a "project"; a simple list of files in a directory (like Sweep's hitherto "open from") is too poor - one needs length indication, sequence/position of cut/pasted bits, if possible some additional content-info field which would allow for entries on the fly (the filename as such is definitely insufficient; from a certain number of clips on, "car-noise-1" to "car-noise-N" gets meaningless, you need "car noise + Sue's cry" and things like that.) Sort of a visual equivalent to the rows of film/tape clips dangling on the gallows left and right of our ancient cutting tables. (Cutmaster has it but there it's rather overkill; I think of an excellent MacApple video editing thingy which is exemplary in its thrifty ergonomy.) BTW, your description of the file browser/manager could as well be an - intermediary ? - idea for the mem handling: > the list allowing you to quickly switch between one or the other > (where you can toggle the state of any one (tabbed or a window) in the > list) > > Radoslaw is working on a navigation bar that should make editing > large files much much easier too. :) -- wouldn't it be meaningful to have just the "baseline file" open, and then just one or a few of the opened/tabbed bits from the "list" ? At least in the present condition this could overcame the MemWallCrash to some degree. And the respective "state" of each clip could be part of what the browser indicates. (Background reflexion: even if "today's" "modern" machines _seem_ to offer almost infinite RAM volume, this is not the reality of everyone's machine; and it's definitely not econmomic. _And_ it unnecessarily cuts out all "older" or poorer equipment which is quite fit for the main task. My "old" socket-7 Mobo with a K6-2/450 MHz and the SB 5.1 produces better sound quality than most humans could hear anyway, bei from CD, FM or DAB radio.) kreetinckx from Brussels, -hc [*] And promptly I read "subversion" as somthing completely different, <bg>. |
From: peter <zen...@ze...> - 2006-09-06 17:41:12
|
On Thu, 2006-08-24 at 03:24 +0100, Heimo Claasen wrote: > A good time ago, around Sweep-0.8.0x, I trampled on Conrad's nerves with > the mem thing; maybe it stimulated his thinking nevertheless. There > isn't much more of a bug report to do on it: simply load a numbwer of > files and Sweep will crash with the "one more drop". right. the out of memory condition could be handled better but can't be avoided whilst sweep maps entire files into memory > Obviously I used the word "timeline" ambiguously[*] (taking it from > traditional cutting/scripting language) - I wouldn't mean "multitracking" > at all, and maybe your "file browser" is already on a good way towards it: > > With cutting/pasting/montage one needs kind of an overview where the > various bits are in the "base file", or are stored, which make part of a > "project"; a simple list of files in a directory (like Sweep's hitherto > "open from") is too poor - one needs length indication, sequence/position > of cut/pasted bits, if possible some additional content-info field which > would allow for entries on the fly sweep deals exclusively with raw sound data represented in slabs of contiguous memory and has no concept of relative time/position (same thing really) what you are talking about is basically a sequencer. in sweep, a view shows a sample. you cannot associate another sample with it except by merging their respective contents in some way. after which you simply have another, different, single sample. so, the "base file" is probably a view of a project rather than of a sample. now, as i understand it, libremix not only frees sweep from it's reliance on editing contiguous slabs of memory but also makes sequencing a possibility. but <insert usual spiel about how i'm an amateur gui hacker and how Conrad is busy with other projects that have a wider significance than sweep and so progress will be made only when it's made etc etc> :) > (the filename as such is definitely > insufficient; from a certain number of clips on, "car-noise-1" to > "car-noise-N" gets meaningless, you need "car noise + Sue's cry" true. but there's not much you can do about it other than merging the contents of the samples and renaming them (or adding some kind of sequencer, without which, groupings don't mean much of anything) > and > things like that.) Sort of a visual equivalent to the rows of film/tape > clips dangling on the gallows left and right of our ancient cutting > tables. > (Cutmaster has it but there it's rather overkill; I think of an excellent > MacApple video editing thingy which is exemplary in its thrifty ergonomy.) speaking of overkill, have you tried ardour? (www.ardour.org) perhaps used in conjunction with sweep (one to sequence, the other to edit) > BTW, your description of the file browser/manager could as well be an > - intermediary ? - idea for the mem handling: > > > the list allowing you to quickly switch between one or the other > > (where you can toggle the state of any one (tabbed or a window) in the > > list) > > > > Radoslaw is working on a navigation bar that should make editing > > large files much much easier too. :) > > -- wouldn't it be meaningful to have just the "baseline file" open, and > then just one or a few of the opened/tabbed bits from the "list" ? At > least in the present condition this could overcame the MemWallCrash to > some degree. And the respective "state" of each clip could be part of > what the browser indicates. well, as far as sweep is concerned, all files are alike. you can chose to see a file as a baseline file then open and close those files that you see as peripheral but there's no way to do it in a functional sense. it would be possible to leave samples in the list even after closing and reload them on demand (if that's what you are suggesting) but it's a kludge at best. i think we'd all be better served by getting 1.0 out the door and getting work started on the libremix stuff. the memory problem effectively goes away then anyway. > (Background reflexion: even if "today's" "modern" machines _seem_ to > offer almost infinite RAM volume, this is not the reality of everyone's > machine; and it's definitely not econmomic. _And_ it unnecessarily cuts > out all "older" or poorer equipment which is quite fit for the main task. > My "old" socket-7 Mobo with a K6-2/450 MHz and the SB 5.1 produces better > sound quality than most humans could hear anyway, bei from CD, FM or DAB > radio.) while sweep is stuck with it's memory problems, you might want to check out mhwaveedit. it's similar to sweep in some ways but has a fully functional jack driver and features on disk editing so if you are short on memory, it might be a better option. cheers, pete. |
From: Radoslaw K. <Rad...@ce...> - 2006-08-29 15:07:13
|
> -----Original Message----- > From: swe...@li...=20 > [mailto:swe...@li...] On Behalf Of peter > Sent: Friday, August 18, 2006 4:54 PM > To: swe...@li... > Subject: Re: [sweep-devel] New Feature Requests / TODO (...) > in terms of fighting with multiple open windows, i want to=20 > add a list of open files and plugin dialogs somewhere along=20 > with the plugin browser that i'm working on now (..and again ;) Could You disclosure some information about it or better some code :) I am thinking on implementing a plugin browser in Information Panel but I don't like to double someone work. Bye. --=20 Rados=B3aw Korzeniewski |
From: peter <zen...@ze...> - 2006-08-30 05:36:59
|
On Tue, 2006-08-29 at 17:07 +0200, Radoslaw Korzeniewski wrote: > > Subject: Re: [sweep-devel] New Feature Requests / TODO > (...) > > in terms of fighting with multiple open windows, i want to > > add a list of open files and plugin dialogs somewhere along > > with the plugin browser that i'm working on now (..and again ;) > > Could You disclosure some information about it or better some code :) > > I am thinking on implementing a plugin browser in Information Panel but > I don't like to double someone work. i didn't know you were working on this and i guess you didn't know i was either. (we have some serious overlap in terms of sidebars and orthogonal ideas for displaying sample information) ok, to avoid this in the future and in lieu of any active oversight, i'm going ask anyone who wants to implement a feature to do the following things *first*: 1: check the trac for an existing enhancement ticket that broadly matches. assign it to yourself or contact who ever is otherwise assigned to it and take it from there. 2: if one doesn't exist, create a new ticket with a description and any other helpful information (mockups, references) 3: if one does exist but it doesn't seem suitable for your purposes, create a new ticket and leave a comment in the similar ticket linking to your new one with a brief explanation. 4: buzz the devel list WRT the new ticket or ticket status. (both the trac and svn support automatic mailing list notification but neither can directly distinguish between projects in a tree afaik so it'll have to be manual for the moment) 5: send me hate mail if i don't heed my own advice ;) this way we can share ideas and avoid wasting time writing duplicate code. for the moment, Radoslaw: this pretty much applies to me and you so with that in mind, i'm off to input some trac enhancement tickets in a moment =] (including one about the plugin browser) as for what we do about the infobar/sidebar... well, germany is about half way between us right? perhaps we could meet there and settle this over a game of scissors paper stone? (or perhaps less expensively, ask Conrad which he prefers. i'll try and turn my hysterical ascii graffiti into a presentable branch for that) cheers, pete. nb: sorry about the spam on the trac. there's no new spam coming in but clearing it out is time consuming so i just left what was there for the moment. |
From: peter <zen...@ze...> - 2006-08-30 07:15:15
|
On Wed, 2006-08-30 at 06:36 +0100, peter wrote: > nb: sorry about the spam on the trac. there's no new spam coming > in but clearing it out is time consuming so i just left what was there > for the moment. scratch that. i just noticed that the trac plugin i installed to delete the spam tickets, also lets me remove ticket changes so most of the spam is gone now. :) cheers, pete. |
From: peter <zen...@ze...> - 2006-08-10 04:25:33
|
On Fri, 2006-08-04 at 12:55 +0300, Juhana Sadeharju wrote: >From: Rados.aw Korzeniewski <rad...@ko...> > > > [ ... ] > > You listed so many items that perhaps we should look if there is > some other editor which already have most of the features, and > then all we should join that project. ;-) > that there be fightin' talk mista! ;) i would add these to Radoslaw's list: insert silence tool generic options dialog to house those new options that would otherwise have no home. Disk Space monitoring (with pervasive alerts and forecasts) resample outputs (apparently the alsa resampler is linear so we should handle it internally until that changes. provide a visual indicator when resampling is in effect? ) drop all drivers bar gstreamer and jack? (someone contacted me on irc expressing an interest in implementing gstreamer I/O themselves. whether it covers enough bases depends on what we want to support i suppose) drop ogg/speex loaders when they are supported by sndfile implement a gstreamer loader? implement a pipe save/loader that can specify params for an external codec (lame binary, wavpack binary etc)? provide default settings for common codecs. (similar to grip) plugin browser with blacklist, categories and bookmarks (i've mostly done this, dunno whether it's worth a damn yet because having designed it, i know very well how it works and so can't easily judge how easy it will be for others to use it.) support for ardour's ladspa preset file format Xv or GL accel for the display? wrap effect tail or grow sample for the tail loop effect n times (grow sample accordingly) and.. many many more i'm sure. ------------------------------- i don't really have many criticisms of those new features that Radoslaw has already listed but the question is one of priority and order. ideally i'd like to clean all the spam out of the trac tickets and then put all these features in. that way we could associate them with releases or other features that need to be implemented first. then create a front page in the trac wiki that lists them all and allows for registered users to leave comments and suggestions. ..ideally ;) it might not be worth it in the long run but i find the idea of a giant flat TODO list to be pretty depressing. so keeping it in the trac allows us to state more clearly which features *would be nice* and which are likely to be implemented in the near future. floating ideas in the trac also makes it convenient for Conrad to veto, OK or otherwise change them in accordance with his vision for sweep. however.. if you hold your breath waiting for me to do this, i'll not be held liable for any damage done when you become unconscious and fall over. =) pete. |
From: Erik de C. L. <ml...@me...> - 2006-08-10 07:26:33
|
peter wrote: > drop all drivers bar gstreamer and jack? Please don't drop ALSA. OSS I couldn't care about, but ALSA is way I use most of the time. > implement a pipe save/loader that can specify params > for an external codec (lame binary, wavpack binary etc)? There's a guy working on Wavpack for libsndfile. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Individual Islamists may appear law-abiding and reasonable, but they are part of a totalitarian movement, and as such, all must be considered potential killers." -- http://www.danielpipes.org/article/3450 |
From: pete <zen...@ze...> - 2006-08-10 12:47:23
|
Erik de Castro Lopo wrote: > peter wrote: > >> drop all drivers bar gstreamer and jack? > > Please don't drop ALSA. OSS I couldn't care about, but ALSA > is way I use most of the time. > no plans to do so. just an idea. gstreamer does support both though. i'll not be making changes that significant without discussing them with Conrad first anyway (and the list). >> implement a pipe save/loader that can specify params >> for an external codec (lame binary, wavpack binary etc)? > > There's a guy working on Wavpack for libsndfile. > cool. though i'm not interested in wavpack per se. (i'm a flac fan) but supporting external codecs adds a lot of flexibility to sweep. dodges patent issues too. (if deprecating mp3 is the order of the day then i guess such a loader presents a problem) > "Individual Islamists may appear law-abiding and reasonable, but they > are part of a totalitarian movement, and as such, all must be considered > potential killers." -- http://www.danielpipes.org/article/3450 that is an extremely polemical and wildly off topic signature and if i see it again i will take it as a personal invitation to discuss that issue right here on the list. and i'm talking in a personal capacity now, not as the sweep maintainer. i prefer to avoid politics and religion when on technical forums to avoid the kind of aggravation the usually results from it. but if you want to drag it in here then that's up to you. pete. |
From: <rad...@ko...> - 2006-08-28 17:17:39
|
On 2006-08-10, at 06:23, peter wrote: > drop all drivers bar gstreamer and jack? > (someone contacted me on irc expressing an interest in > implementing gstreamer I/O themselves. whether it covers enough > bases depends on what we want to support i suppose) I think that we should implement modular driver framework which allow use any of sound subsystem available today or in the future (or =20 available on different platforms). > drop ogg/speex loaders when they are supported by sndfile > implement a gstreamer loader? > > implement a pipe save/loader that can specify params > for an external codec (lame binary, wavpack binary etc)? > provide default settings for common codecs. (similar to grip) Another example for modular drivers (sound file drivers :). We should implement general framework for loading/saving sound files and on top of that we can handle different features. > Xv or GL accel for the display? No, Xv and GL are for different purposes. We should use libcairo for drawing like newest gtk do. > i don't really have many criticisms of those new features that > Radoslaw has already listed but the question is one of priority > and order. Its not a bad idea to have a lot of different new features on TODO list. More development, more fun to get :). > it might not be worth it in the long run but i find the idea of > a giant flat TODO list to be pretty depressing. As You wish. Trac tickets are more useful that flat TODO file, so You =20= have my vote for trac. bye --=20 Rados=C5=82aw Korzeniewski rad...@ko... |
From: Erik de C. L. <ml...@me...> - 2006-08-10 07:24:54
|
Juhana Sadeharju wrote: > >From: Rados.aw Korzeniewski <rad...@ko...> > > > [ ... ] > > You listed so many items that perhaps we should look if there is > some other editor which already have most of the features, and > then all we should join that project. ;-) The reason this editor exists and people are still willing to maintain it is because the others suck so bad. This editor also has features that none of the other ones have (like scrubby, stoping/starting play of multiple files simultaneously etc). > Could Ardour be modified to include Sweep-type application? Probably not. > Audacity is already excellent but has annoying features as well. I find Audacity a PITA. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Safety versus Expressiveness is a false dichotomy -- you can have both. Compare ObjectiveCaml with CeePlusPlus: OCaml obtains expressiveness without compromising safety, while C++ obtains it by throwing away safety. The latter is just bad design." -- David Hopwood |
From: pete <zen...@ze...> - 2006-08-10 12:45:37
|
Erik de Castro Lopo wrote: > peter wrote: > >> drop all drivers bar gstreamer and jack? > > Please don't drop ALSA. OSS I couldn't care about, but ALSA > is way I use most of the time. > no plans to do so. just an idea. gstreamer does support both though. i'll not be making changes that significant without discussing them with Conrad first anyway (and the list). >> implement a pipe save/loader that can specify params >> for an external codec (lame binary, wavpack binary etc)? > > There's a guy working on Wavpack for libsndfile. > cool. though i'm not interested in wavpack per se. (i'm a flac fan) but supporting external codecs adds a lot of flexibility to sweep. dodges patent issues too. (if deprecating mp3 is the order of the day then i guess such a loader presents a problem) > "Individual Islamists may appear law-abiding and reasonable, but they > are part of a totalitarian movement, and as such, all must be considered > potential killers." -- http://www.danielpipes.org/article/3450 that is an extremely polemical and wildly off topic signature and if i see it again i will take it as a personal invitation to discuss that issue right here on the list. and i'm talking in a personal capacity now, not as the sweep maintainer. i prefer to avoid politics and religion when on technical forums to avoid the kind of aggravation the usually results from it. but if you want to drag it in here then that's up to you. pete. |
From: Thorsten W. <t_...@fr...> - 2006-08-10 12:56:07
|
On Thu, Aug 10, 2006 at 01:45:27PM +0100, pete wrote: > cool. though i'm not interested in wavpack per se. (i'm a flac fan) Different from flac, wavpack handles float, so you can compress the typical 32bit float jack audio WAVs directly and truly losless. > > "Individual Islamists may appear law-abiding and reasonable, but they > > are part of a totalitarian movement, and as such, all must be considered > > potential killers." -- http://www.danielpipes.org/article/3450 > > that is an extremely polemical and wildly off topic signature and if i > see it again > i will take it as a personal invitation to discuss that issue right here > on the list. > and i'm talking in a personal capacity now, not as the sweep maintainer. Almost everyone is a potential killer, so that statement is stupid anyway. Oops, sorry :) -- Thorsten Wilms |