loopdub-devel Mailing List for LoopDub (Page 2)
Brought to you by:
radarsat1
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(6) |
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(21) |
2008 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stephen S. <rad...@gm...> - 2007-12-27 22:27:47
|
> I did notice that. My position is that it doesn't really matter, since > the directory browsing is still essentially instantaneous, from a user > experience point of view. I'm not saying it's a good thing, but in > terms of things to clean up in the code, there are probably more > important things to tackle first. True. The history of it is that I originally assumed it might be useful to be able to browse to different directories for each loop. During a frustating set where I had to subsequently manually move each browser one-by-one to the correct subdir, I realized this was a very bad idea, so I patched it quickly and forgot about it.. Steve |
From: Nick T. <nh...@gm...> - 2007-12-26 10:08:54
|
There are a couple defaults in LoopDub that I don't like. The default button mode is cue, where I would like it to be hold, and the default loop volume is 100%, where I want it to be 0%. So I was thinking that maybe this sort of thing should be configurable. I've attached a patch which implements another configuration file, .loopdub.conf, which contains this sort of general configuration information. The two things I mentioned, default button mode and default volume, are the only configuration parameters that I've implemented. Anyway, tell me what you think of this idea. |
From: Nick T. <nh...@gm...> - 2007-12-26 07:09:15
|
You may be aware that many MIDI controllers on the market have the ability to not only send MIDI messages to another device, but to receive MIDI messages from another device. This causes the setting of the physical controller on the device to change. In the case of faders, the faders are usually motorized. In the case of knobs, they are usually LED rotary encoders. What's nice about this feature is that it's an easy way to make sure that the controls on the device are consistent with the controls in the software. My own controller has this feature. Anyway, I have attached a patch to exploit this functionality with LoopDub. It does two things. First, it adds MIDI output support to LoopDub. (A lot of the infrastructure for this seems to have already been present; perhaps LoopDub has supported MIDI output in the past?) Second, it adds a new user interface function: when the user presses 'S' (for 'synchronize'), CC messages corresponding to the current values for all volume and effect sliders will be sent to the MIDI output. Now, this is not 'proper' support for MIDI synchronization; it's merely a useful first step. To really do it right, you'd also need to modify the code so that whenever a slider changes in value, a corresponding MIDI CC message is sent to the output. If you do this, then the controller knob and the software parameter will always move in unison; when one changes, the other makes a corresponding change. Unfortunately, it looks like implementing this in a clean, DRY way would require a bit of refactoring of the code. As far as I can tell, the controller values are stored in the slider objects, and they get modified all over the place. The most obvious way to do this would be to have the slider objects themselves send the MIDI messages, but the trouble is that they don't know anything about MIDI, being simple user-interface objects. With that in mind, I propose the following refactoring. We should add two new functions to the LoopOb class: double GetController(int ctrl); void SetController(int ctrl, CtrlSource source, double value); These will get or set a given controller (level or effect) value. 0 for level, 1-4 for effects. The controller values will be stored as doubles within the LoopOb itself as a new private member: double m_ctrlValues[5]; The use of these functions will supersede the use of all other methods for setting controller values in a LoopOb. The SetController function, in addition to storing the value internally as a double, will synchronize the GUI slider and the MIDI slider with the new value. Only one problem: we don't want to "synchronize" a controller that was the source of the parameter change. E.g., if the SetController function was called due to the user adjusting a control on their MIDI controller, we don't want to send a MIDI CC back the controller. Not only is it redundant, it might interfere with the user's adjustment of the controller. Obviously, an adjustment of a parameter consists of many MIDI CC messages. If they send the next one in the set before we send back our (redundant) synchronization CC, then the synchronization CC will arrive after the parameter has changed on the controller and undo the user's work in adjusting the control. I don't know if this would be an issue in practice, but it seems like a possibility. Anyway, that is the purpose of the 'source' parameter to the SetController function. It can take on three values: enum CtrlSource { SRC_INTERNAL = 0, SRC_GUI = 1, SRC_MIDI = 2 }; The second two are self-explanatory. The first is for adjustments that are done automatically by the program. The SetController function uses the source parameter to know not to synchronize the GUI if the source of the change was the GUI, and not to synchronize MIDI if the source of the change was MIDI. Obviously, implementing these changes will require modification not only of the LoopOb class, but of all of the code that reads or modifies control parameters. If you agree that this is a good design, then I will go ahead with those changes. P.S.: The attached patch was made against LoopDub 0.3, not against the latest git. Is that an issue? The previous patch was, as well. I ask now only because this patch is far more invasive than the previous one. |
From: Nick T. <nh...@gm...> - 2007-12-26 05:46:05
|
On Dec 26, 2007 12:30 AM, Stephen Sinclair <rad...@gm...> wrote: > I merged it in just now, so it's in the git master. > Just a note, I removed the "- 1" in the for (... m_nNames-1). > Any reason for it? Probably that I wrote the patch at 4:00AM. ;-) Thanks for catching my bug. > I think in general the file stuff will have to be optimized better... > I forgot that each file browser is still loading directory itself, so > the directory listing (and thus, the sort) is unnecessarily performed > 8 times! > Whoops. I did notice that. My position is that it doesn't really matter, since the directory browsing is still essentially instantaneous, from a user experience point of view. I'm not saying it's a good thing, but in terms of things to clean up in the code, there are probably more important things to tackle first. |
From: Stephen S. <rad...@gm...> - 2007-12-26 05:30:36
|
> Here's a quick patch to have the filenames in the file browser sorted > alphabetically. Great! And on Christmas too.. :) I merged it in just now, so it's in the git master. Just a note, I removed the "- 1" in the for (... m_nNames-1). Any reason for it? It was causing the algorithm to miss sorting the last item in the list. I think in general the file stuff will have to be optimized better... I forgot that each file browser is still loading directory itself, so the directory listing (and thus, the sort) is unnecessarily performed 8 times! Whoops. cheers, Steve |
From: Nick T. <nh...@gm...> - 2007-12-25 08:52:01
|
Here's a quick patch to have the filenames in the file browser sorted alphabetically. |
From: Stephen S. <rad...@gm...> - 2007-12-23 18:25:12
|
> I have a Behringer BCR-2000: Cool, it's quite similar to the UC-33, except that my bottom row is sliders instead of knobs. (I use them for volume of course..) > The first button, > when toggled on, sets feedback to a fixed value, and then back to zero That is quite a good idea! I have always felt wanting for another row of knobs to control the delay properly... 5 controls. Never thought of using the buttons for this purpose. (Eventually though I'll make it support multiple input devices.. although I suppose it already does if you make the connection using the "aconnectgui" ALSA application.) Maybe I should put together a "tip sheet" for examples of how to configure MIDI for loopdub... Happy holidays, Steve |
From: Nick T. <nh...@gm...> - 2007-12-23 17:57:49
|
On Dec 23, 2007 12:36 PM, Stephen Sinclair <rad...@gm...> wrote: > Out of curiosity, which controller do you have? > I have a Behringer BCR-2000: http://www.behringer.com/BCR2000/index.cfm?lang=eng Works quite nicely for LoopDub, as it happens; eight strips of four knobs and two buttons each (plus the four extra buttons). The knobs are mapped to volume, cutoff, resonance, and delay. The first button, when toggled on, sets feedback to a fixed value, and then back to zero when toggled off; I find that this is good enough for me000. The second button I will map to LoopDub's "button" feature when I next boot back into Linux. > Don't hesitate if you have any more questions... > there are few loopdub users at present, so any feedback is helpful. > I will not. :-) |
From: Stephen S. <rad...@gm...> - 2007-12-23 17:36:45
|
> No, I can program them to send CC messages. Cool, that should help! :) Out of curiosity, which controller do you have? Don't hesitate if you have any more questions... there are few loopdub users at present, so any feedback is helpful. cheers, Steve |
From: Nick T. <nh...@gm...> - 2007-12-23 07:28:19
|
On Dec 22, 2007 8:59 PM, Stephen Sinclair <rad...@gm...> wrote: > There is a list of MIDI messages called "Button.0" to "Button.7". > These are the buttons that correspond to each track. Then there is a > list of messages called "Select.0" to "Select.7". These each > correspond to a "button mode". So, sending the CC message assigned to > Select.2 will put it in "hold" mode, and then sending any of the > Button.N messages will hold whichever track you want. > Thanks! That clears things up nicely. > If you've only got 8 buttons available, you'll probably want to set a > default "mode", which is currently "cue" (admittedly a bad choice). > Unfortunately there's no way to set the default in the configuration > file, it'll take a code change. > I actually have four unused buttons left on my controller; I will configure them as the select buttons. > Also, your situation seems to call for note-on/note-off messages to > control these buttons... on my controllers the buttons send CC > messages, so I think some code changes would need to be made for that > as well. > No, I can program them to send CC messages. > All in all the configuration stuff probably needs some work to be more > flexible. I'll see what I can do... > Well, luckily my own box is flexible enough to compensate for LoopDub's lack of flexibility. ;-) But yes, eventually someone will probably not be as lucky as me. Thanks for the info! |
From: Stephen S. <rad...@gm...> - 2007-12-23 01:59:44
|
Hi Nick, > I have a MIDI control surface with eight buttons on it that are programmed > to send noteon/noteoff messages. I would like to use these buttons, one per > loop, to trigger the "hold" feature in LoopDub. Is this possible? There's > some allusion in the documentation (which is, I believe, out of date?) to > "MIDI buttons," but no specifics. Yes that's definitely possible. I agree it's probably not clear in the documentation, so I'll try to address that. LoopDub was designed somewhat after the MIDI interfaces I have available to me.. I have a UC-33 controller which has several buttons with numbers on them (1-9) and then assignable four buttons at the bottom. I assigned the four buttons to select a "button mode", which tells loopdub what should happen when one of the number buttons is pushed. When the button mode is in "Hold" mode, then sending one of the CC messages for the number buttons will "hold" that track. So take a look at the included loopdub.midi.conf: There is a list of MIDI messages called "Button.0" to "Button.7". These are the buttons that correspond to each track. Then there is a list of messages called "Select.0" to "Select.7". These each correspond to a "button mode". So, sending the CC message assigned to Select.2 will put it in "hold" mode, and then sending any of the Button.N messages will hold whichever track you want. If you've only got 8 buttons available, you'll probably want to set a default "mode", which is currently "cue" (admittedly a bad choice). Unfortunately there's no way to set the default in the configuration file, it'll take a code change. Also, your situation seems to call for note-on/note-off messages to control these buttons... on my controllers the buttons send CC messages, so I think some code changes would need to be made for that as well. All in all the configuration stuff probably needs some work to be more flexible. I'll see what I can do... cheers, Steve |
From: Nick T. <nh...@gm...> - 2007-12-23 01:25:57
|
I have a MIDI control surface with eight buttons on it that are programmed to send noteon/noteoff messages. I would like to use these buttons, one per loop, to trigger the "hold" feature in LoopDub. Is this possible? There's some allusion in the documentation (which is, I believe, out of date?) to "MIDI buttons," but no specifics. |
From: Stephen S. <rad...@gm...> - 2007-12-22 03:57:39
|
Hi, This is to announce that version 0.3 of LoopDub has been released on sourceforge. Head over to http://loopdub.sf.net to pick it up. This release introduces few new features, but encompasses mostly infrastructural changes that will affect future development. For instance, * change to git for managing the versioned code * change to RtAudio and RtMidi for cross-platform audio and midi back-end support * change to SCons for building and code configuration A lot of these changes have been sitting in the subversion repository for ever, so rather than keep waiting for some features I thought it best to just do a release, since I've occasionally gotten email about compiling version 0.2 which I'm no longer developing. Hopefully this will open up the way to more development on LoopDub, such as better MIDI support and incorporation of the OSC protocol. Some small features have been introduced: * "Loop Folder" button to allow navigating outside the initially-selected loop folder. * Display the "button mode" i.e., visual feedback for what will happen when a track button is pushed * Programs can be loaded by typing their number on the computer keyboard instead of only from MIDI program-change message. cheers, Steve |
From: Stephen S. <rad...@gm...> - 2006-12-30 06:09:44
|
Hi Serguei! Been a while. :) That's interesting, hadn't heard of Ohloh before. I like the "Project Cost" section. :) To the list: I've had a bit of time to work on LoopDub over the holidays. I'm trying to fix up a script called "bootstrap.sh" which downloads and compiles all dependancies for the operating system in question. So far it seems to work on Linux, OSX, and Cygwin, but no guarantees. I'm also currently trying to knock down some of my roadmap items for v0.3, and doing general, much-needed, code cleanup. Semester starts again in like 3 days though, I hope to have _something_ to show by then. Happy new year folks, Steve On 12/30/06, Serguei A. Mokhov <mo...@cs...> wrote: > Hey Steve, > > How are ya? > > Just to inform you I added loopdub for source code analysis at ohloh.org > (they analyse the code from the repo and get various kind of stats on the > project development, etc. and periodically download the increments from > the repo too). Just out of curiosity I added loopdub there too :-) > > http://ohloh.org/projects/3776 > > Happy New Year! |
From: Serguei A. M. <mo...@cs...> - 2006-12-30 05:37:35
|
Hey Steve, How are ya? Just to inform you I added loopdub for source code analysis at ohloh.org (they analyse the code from the repo and get various kind of stats on the project development, etc. and periodically download the increments from the repo too). Just out of curiosity I added loopdub there too :-) http://ohloh.org/projects/3776 Happy New Year! -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email! |
From: Brian S. <sug...@gm...> - 2006-09-07 15:28:07
|
I too have an AMD 64 bit processor. I gave up on 64 bit Ubuntu and am now running the 32 bit version. I had too many issues. None now. Well...except...I'm not really using my processor for what it was meant for. Nice move with libsndfile! I'll look into some good libraries for supporting ogg, flac, and mp3. Is aac an Apple format? It shows up on my radar every once and a while, but I haven't actually touched such a file. I like RtAudio and RtMidi alot. Another good call. I'm not sure how active the development is, but it's still used in college courses at, I think, McGill University. Shout when you've got everything checked into CVS. On 9/7/06, Stephen Sinclair <rad...@gm...> wrote: > > > Have you looked at FLTK? It tends to be my favorite x-platform GUI kit > > these days. If all you need is a main window and a few dialogs here and > > there, it's worth evaluating. I've built a few things for both > Win/Linux > > with good results. It supports Mac, though I've no experience. It's > small > > enough to include statically too. > > I'm going to take a deeper look at it. Might be the right thing. Then > again since it's just a matter of selecting a directory, building it > right into LoopDub might be the best thing to do... > (I've already got a "file selector" widget in there, so it shouldn't > be too much trouble.) > > Some other things of note I've been working on some changes regarding > the back-end.. > (You can always tell when I've taken the time to do some work on > LoopDub.. it's almost always when I've got a gig coming up.. ;-) > > I am finally getting fed up with autotools, so I whipped up a little > Scons script, and it's so much better. (Or at least, easier.) I'll > probably include a little "bootstrap.sh" to download & run it. Only > tested on Linux so far... > > Also, I got some serious errors last time I played with LoopDub from > the PortMidi library. Additionally, some problems with PortAudio, > possibly related to getting it working on 64-bit Ubuntu. So I've > decided to just ditch those two. I've been thinking about doing it > for a while... I'm at the moment working on switching to RtAudio and > RtMidi instead. They seem to fit better with the C++ paradigm anyways. > (Part of the STK package.) > > Lastly, when I first ported to OS X, I had all sorts of endian-related > problems in my wav loading routine. Now, again, porting to 64-bit, > I've run into similar issues. So again I got that feeling of "enough > is enough", and I finally got around to ditching that routine and > replacing it with libsndfile. I should have done it long ago! The > file loading routine is only a few lines long now, and supports any > format that libsndfile supports. (Which is a lot.) > > I'd like to integrate mp3 and ogg support sometime, and this is a good > step towards that. > > (It's too bad that libsndfile doesn't seem to support compressed > formats, actually.. I understand the mp3 license thing, but it would > be nice if they included vorbis support. Any suggestions on a library > that supports ogg, flac, aac, etc? Maybe libmplayer...) > > Oh, I should note that I haven't dumped this stuff into CVS yet. Still > working on it... expect it this weekend or early next week though. > > > Steve > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Loopdub-devel mailing list > Loo...@li... > https://lists.sourceforge.net/lists/listinfo/loopdub-devel > |
From: Brian S. <sug...@gm...> - 2006-09-07 14:58:47
|
Yeah, since I started playing around with SoundTouch I've run into these same questions/issues. I'm prototyping different ways of handling the situation you describe. I'll work on your suggestions during my next coding fit. In one prototype, I end up looping some samples multiple times during a single loop of longer samples. For example - My longest sample is 4 measures with a tempo of 176. Other samples might be 1 or 2 measures at different tempos. In the prototype I dynamically figure out how many times the shorter samples can loop within 1 loop of the longer clip(s), and re-trigger them accordingly. At the same time, I'm beatmatching everything. It's kinda working, and the code is a mess right now. In a second prototype, I simply play shorter samples only once during a single pass of the longer sample(s). That works well, but is less interesting to listen to. Again, shorter samples are beatmatched. A third prototype is a variation of the second where shorter samples loop exactly twice during a single loop of the longer sample(s). It results in some sound decay, but causes some happy accidents to occur. This tends to be my favorite at the moment. It's possible to support the features of the 3 prototypes, but making it intuitive in the UI is the hardest challenge. My prototypes also assume the longest loop is loaded first and remains in the mix for the duration of playback. New longer loops are beatmatched to the existing tempo. I also haven't considered how to change the tempo during playback. Right now I lock you into the tempo of the first longest sample. It's as if there is a "master" sample. Lately I've been thinking that LoopDub needs a tempo/bpm widget? Perhaps a slider or a dial/pot that can be used during playback to slow things down or speed 'em up. That way the user is in control of the tempo. This would definitely build in a hard dependency on SoundTouch or a similar lib/algorithm for basic operation. Also, reanalysing the sample data might cause an occasional audio glitch during playback. I don't know. So many ideas and directions. On 9/7/06, Stephen Sinclair <rad...@gm...> wrote: > > Hi, > > I had some thoughts on the bus on the way to work this morning, about > how to handle sample stretching and timing changes. > > The basic problem is this: > > At the moment, LoopDub expects all loops to be the same size. You can > quite easily load a loop which is half or a quarter of the "loop > size", and it will happily loop it in sync. However, load something > which is at a different tempo, and you'll get an unexpected effect. > It won't stretch it to the right size, or anything. Load something > which is exactly twice the "loop size" and it will loop back to the > beginning at the half-way mark. > > So far, this is "by design". However, it would be nice if LoopDub had > at least a manual way to handle situations where you want to stretch > or compress a sample, or alternatively change tempo. We've talked > about using the SoundTouch library to do the stretching, but not > really how to present this option to the user in a way that won't > hinder the expected behaviour of the program. > > That is -- if I'm playing at 130 BPM, and I want to switch to > drum'n'bass music, I'll load a loop that is at, say, 160 BPM, which > will be a different length. Should LoopDub "resize" this loop to 130 > BPM, or should it change the tempo? And if the tempo changes, what > should happen to the other loops? (If it continues to play them after > changing tempo, they will be out of sync, and will sound like crap. > Should it stretch all other loops to the new size?) > > I suppose the only way to handle it, for now, at least, is to give > manual control to the user. (Perhaps after playing with it manually, > a more automatic approach will become obvious.) > > So, I propose adding a new column of buttons to the left side of each > loop: > > * Length > * Stretch > * Rec > > Length: Make this sample's length the "loop length". All loops will > start to loop at the end of THIS sample. (Will take effect the next > time the currently-playing loop gets back to the beginning, similar to > Hold and Switch.) > > Stretch: Stretch this sample to the same size as the current "loop > length". This would be useful for loading off-tempo loops that you > wish to play at the current tempo, OR for re-stretching existing loops > after tempo has changed. This latter operation would probably be > somewhat difficult to do "in time" before it audibly becomes obvious > that there are two different tempos playing... not sure what to do > about that, or if it's even necessary to worry about it. I imagine > tempo changes would be done with non-beat sorts of sounds anyways.. > > Rec: Well, maybe I will not implement this right away, but I've been > wanting to add a facility for recording a loop through the mic or line > input. May as well add it here. > > > Steve > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Loopdub-devel mailing list > Loo...@li... > https://lists.sourceforge.net/lists/listinfo/loopdub-devel > |
From: Stephen S. <rad...@gm...> - 2006-09-07 14:00:22
|
Hi, I had some thoughts on the bus on the way to work this morning, about how to handle sample stretching and timing changes. The basic problem is this: At the moment, LoopDub expects all loops to be the same size. You can quite easily load a loop which is half or a quarter of the "loop size", and it will happily loop it in sync. However, load something which is at a different tempo, and you'll get an unexpected effect. It won't stretch it to the right size, or anything. Load something which is exactly twice the "loop size" and it will loop back to the beginning at the half-way mark. So far, this is "by design". However, it would be nice if LoopDub had at least a manual way to handle situations where you want to stretch or compress a sample, or alternatively change tempo. We've talked about using the SoundTouch library to do the stretching, but not really how to present this option to the user in a way that won't hinder the expected behaviour of the program. That is -- if I'm playing at 130 BPM, and I want to switch to drum'n'bass music, I'll load a loop that is at, say, 160 BPM, which will be a different length. Should LoopDub "resize" this loop to 130 BPM, or should it change the tempo? And if the tempo changes, what should happen to the other loops? (If it continues to play them after changing tempo, they will be out of sync, and will sound like crap. Should it stretch all other loops to the new size?) I suppose the only way to handle it, for now, at least, is to give manual control to the user. (Perhaps after playing with it manually, a more automatic approach will become obvious.) So, I propose adding a new column of buttons to the left side of each loop: * Length * Stretch * Rec Length: Make this sample's length the "loop length". All loops will start to loop at the end of THIS sample. (Will take effect the next time the currently-playing loop gets back to the beginning, similar to Hold and Switch.) Stretch: Stretch this sample to the same size as the current "loop length". This would be useful for loading off-tempo loops that you wish to play at the current tempo, OR for re-stretching existing loops after tempo has changed. This latter operation would probably be somewhat difficult to do "in time" before it audibly becomes obvious that there are two different tempos playing... not sure what to do about that, or if it's even necessary to worry about it. I imagine tempo changes would be done with non-beat sorts of sounds anyways.. Rec: Well, maybe I will not implement this right away, but I've been wanting to add a facility for recording a loop through the mic or line input. May as well add it here. Steve |
From: Stephen S. <rad...@gm...> - 2006-09-07 13:40:28
|
> Have you looked at FLTK? It tends to be my favorite x-platform GUI kit > these days. If all you need is a main window and a few dialogs here and > there, it's worth evaluating. I've built a few things for both Win/Linux > with good results. It supports Mac, though I've no experience. It's small > enough to include statically too. I'm going to take a deeper look at it. Might be the right thing. Then again since it's just a matter of selecting a directory, building it right into LoopDub might be the best thing to do... (I've already got a "file selector" widget in there, so it shouldn't be too much trouble.) Some other things of note I've been working on some changes regarding the back-end.. (You can always tell when I've taken the time to do some work on LoopDub.. it's almost always when I've got a gig coming up.. ;-) I am finally getting fed up with autotools, so I whipped up a little Scons script, and it's so much better. (Or at least, easier.) I'll probably include a little "bootstrap.sh" to download & run it. Only tested on Linux so far... Also, I got some serious errors last time I played with LoopDub from the PortMidi library. Additionally, some problems with PortAudio, possibly related to getting it working on 64-bit Ubuntu. So I've decided to just ditch those two. I've been thinking about doing it for a while... I'm at the moment working on switching to RtAudio and RtMidi instead. They seem to fit better with the C++ paradigm anyways. (Part of the STK package.) Lastly, when I first ported to OS X, I had all sorts of endian-related problems in my wav loading routine. Now, again, porting to 64-bit, I've run into similar issues. So again I got that feeling of "enough is enough", and I finally got around to ditching that routine and replacing it with libsndfile. I should have done it long ago! The file loading routine is only a few lines long now, and supports any format that libsndfile supports. (Which is a lot.) I'd like to integrate mp3 and ogg support sometime, and this is a good step towards that. (It's too bad that libsndfile doesn't seem to support compressed formats, actually.. I understand the mp3 license thing, but it would be nice if they included vorbis support. Any suggestions on a library that supports ogg, flac, aac, etc? Maybe libmplayer...) Oh, I should note that I haven't dumped this stuff into CVS yet. Still working on it... expect it this weekend or early next week though. Steve |
From: Brian S. <sug...@gm...> - 2006-09-01 16:44:31
|
A Suse RPM! Very nice. Have you looked at FLTK? It tends to be my favorite x-platform GUI kit these days. If all you need is a main window and a few dialogs here and there, it's worth evaluating. I've built a few things for both Win/Linux with good results. It supports Mac, though I've no experience. It's small enough to include statically too. Also consider a config file for LoopDub. The user can specify the dir using a simple key=value line. LoopDub could then read that config file on startup. This will allow Win/Mac users to click a shortcut instead of using the command line. I'll try and conjur up some other ideas. It would be a bummer to have to rework the UI. On 9/1/06, Stephen Sinclair <rad...@gm...> wrote: > > Heh, I did a random search for LoopDub yesterday and discovered that > someone has apparently taken the initiative to package it for Suse > Linux! > > http://rpm.pbone.net/index.php3?stat=3&search=loopdub&srodzaj=3 > > Awesome :) > > I've been thinking of making Debian, Ubuntu and Fedora rpm/debs, but > figured I would wait for a more advanced version. > > My current thinking is that the major show-stopper for binary release > right now is that it stupidly depends on the command line just to tell > it what folder your music is in. > > I'd really like to write a "launcher" or something that will set the > "base" folder before running LoopDub. However, GUI stuff always gets > pretty icky when you go cross-platform. I don't particularly feel > like relying on big libraries like wxWidgets just to pop up a file > dialog! > > Perhaps I could build something into LoopDub, though I was hoping to > avoid ever having a "preferences" screen. However I'm starting to > think it will be necessary.. also for selecting things like prefered > audio and midi drivers. I very much want to build in Jack support, so > this will have to be selected somehow, and although I obviously don't > mind using the command line, it probably won't cut it for Windows and > OS X versions. > > On a side-note, I bought a beautiful new laptop yesterday. Feels > funny spending so much money, since I've even been putting off getting > an MP3 player due to my student-poor status, but I really needed it > both for school and music, and have been working all summer. I've been > on the verge of turning down gigs just cause I didn't have a laptop! > > So anyways I'm now powered by a nice 64-bit Turion X2 (dual core!)... > and it's wonderful. I can't wait to install Ubuntu... this also means > LoopDub will be 64-bit-ready soon enough. > > (Don't you just love being forced to pay for a Windows license when > you're just going to erase it after?? ahhh..) > > > Steve > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Loopdub-devel mailing list > Loo...@li... > https://lists.sourceforge.net/lists/listinfo/loopdub-devel > |
From: Stephen S. <rad...@gm...> - 2006-09-01 14:47:14
|
Heh, I did a random search for LoopDub yesterday and discovered that someone has apparently taken the initiative to package it for Suse Linux! http://rpm.pbone.net/index.php3?stat=3&search=loopdub&srodzaj=3 Awesome :) I've been thinking of making Debian, Ubuntu and Fedora rpm/debs, but figured I would wait for a more advanced version. My current thinking is that the major show-stopper for binary release right now is that it stupidly depends on the command line just to tell it what folder your music is in. I'd really like to write a "launcher" or something that will set the "base" folder before running LoopDub. However, GUI stuff always gets pretty icky when you go cross-platform. I don't particularly feel like relying on big libraries like wxWidgets just to pop up a file dialog! Perhaps I could build something into LoopDub, though I was hoping to avoid ever having a "preferences" screen. However I'm starting to think it will be necessary.. also for selecting things like prefered audio and midi drivers. I very much want to build in Jack support, so this will have to be selected somehow, and although I obviously don't mind using the command line, it probably won't cut it for Windows and OS X versions. On a side-note, I bought a beautiful new laptop yesterday. Feels funny spending so much money, since I've even been putting off getting an MP3 player due to my student-poor status, but I really needed it both for school and music, and have been working all summer. I've been on the verge of turning down gigs just cause I didn't have a laptop! So anyways I'm now powered by a nice 64-bit Turion X2 (dual core!)... and it's wonderful. I can't wait to install Ubuntu... this also means LoopDub will be 64-bit-ready soon enough. (Don't you just love being forced to pay for a Windows license when you're just going to erase it after?? ahhh..) Steve |
From: Brian S. <sug...@gm...> - 2006-08-07 19:15:55
|
"By the way, the "two developers" includes me and you, Brian. :)" Yeah, I know. I'm a little too hopeful I suppose. Yes, configure worked for me on Linux (Ubuntu 6.06). I'm running very recent versions of the autotools too. I don't know about the configure step. Does it add enough value to the build process? Personally I'd pass with only 4...well...really 3 dependencies. But you may have better insight than me. Eclipse CDT is very slick. It uses alot of memory, but it's worth it IMO because you get some handy features like refactoring (albeit simple). What I did was run configure against my project directory and imported the makefile. When I want to rebuild I just right-click the project and select "build project". It's working reliably so far with a little hand tweaking here and there. I'm going to try and convert the project to a "managed make" project soon. I'll keep you posted on the progress. If nothing else, it'll be a nice "howto" for developers who want to use Eclipse. Brian On 8/7/06, Stephen Sinclair <rad...@gm...> wrote: > > Heheh.. > If I'm ever in Washington I'll look you up. :) > > By the way, the "two developers" includes me and you, Brian. :) > > You said you are using a manual Makefile. Have you had any success > running "./configure" under Linux? I don't know, maybe I shouldn't > use autotools. I'm having trouble getting it working correctly under > OSX, though potentially it should work fine under that as well as > Cygwin, if I could just get it configured properly. > > Let me know if you have luck with Eclipse. I've used it only for some > Java stuff. > > > Steve > > > > On 8/7/06, Brian Suojanen <sug...@gm...> wrote: > > Yep - works! > > > > I'm hackin' away; I decided to try Eclipse with CDT because it's > consistent > > across Linux and Windows (using MinGW). This will allow me to verify my > > code on both platforms, and help Stephen in porting issues. I've got > > LoopDub to build on Linux using a "manual make" project. With code > > insight/completion; I should be more productive. > > > > So far I'm trying variations of a SamplePool object, an object pool > specific > > to samples in LoopDub. Related to that, I'm working on adding routines > > using the SoundTouch library. These features will be toggled on/off in > the > > interface. > > > > I don't intend to add these features to the current codebase until after > > Stephen has LoopDub building consistently on Win32 and OS X, and he's > given > > me the okay. If you want a sneak peak before then, I'll be more than > glad > > to share my code. > > > > Welcome aboard! BTW, I DJ at the Marx Cafe in Washington, DC on > Wednesday > > nights; I'll be using LoopDub this week for the first time; I've got a > ton > > of original material that I want to play out. Stop by the DJ booth if > you > > get a chance. > > > > - Brian > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Loopdub-devel mailing list > Loo...@li... > https://lists.sourceforge.net/lists/listinfo/loopdub-devel > |
From: Stephen S. <rad...@gm...> - 2006-08-07 17:22:21
|
Heheh.. If I'm ever in Washington I'll look you up. :) By the way, the "two developers" includes me and you, Brian. :) You said you are using a manual Makefile. Have you had any success running "./configure" under Linux? I don't know, maybe I shouldn't use autotools. I'm having trouble getting it working correctly under OSX, though potentially it should work fine under that as well as Cygwin, if I could just get it configured properly. Let me know if you have luck with Eclipse. I've used it only for some Java stuff. Steve On 8/7/06, Brian Suojanen <sug...@gm...> wrote: > Yep - works! > > I'm hackin' away; I decided to try Eclipse with CDT because it's consistent > across Linux and Windows (using MinGW). This will allow me to verify my > code on both platforms, and help Stephen in porting issues. I've got > LoopDub to build on Linux using a "manual make" project. With code > insight/completion; I should be more productive. > > So far I'm trying variations of a SamplePool object, an object pool specific > to samples in LoopDub. Related to that, I'm working on adding routines > using the SoundTouch library. These features will be toggled on/off in the > interface. > > I don't intend to add these features to the current codebase until after > Stephen has LoopDub building consistently on Win32 and OS X, and he's given > me the okay. If you want a sneak peak before then, I'll be more than glad > to share my code. > > Welcome aboard! BTW, I DJ at the Marx Cafe in Washington, DC on Wednesday > nights; I'll be using LoopDub this week for the first time; I've got a ton > of original material that I want to play out. Stop by the DJ booth if you > get a chance. > > - Brian |
From: Brian S. <sug...@gm...> - 2006-08-07 17:13:21
|
Yep - works! I'm hackin' away; I decided to try Eclipse with CDT because it's consistent across Linux and Windows (using MinGW). This will allow me to verify my code on both platforms, and help Stephen in porting issues. I've got LoopDub to build on Linux using a "manual make" project. With code insight/completion; I should be more productive. So far I'm trying variations of a SamplePool object, an object pool specific to samples in LoopDub. Related to that, I'm working on adding routines using the SoundTouch library. These features will be toggled on/off in the interface. I don't intend to add these features to the current codebase until after Stephen has LoopDub building consistently on Win32 and OS X, and he's given me the okay. If you want a sneak peak before then, I'll be more than glad to share my code. Welcome aboard! BTW, I DJ at the Marx Cafe in Washington, DC on Wednesday nights; I'll be using LoopDub this week for the first time; I've got a ton of original material that I want to play out. Stop by the DJ booth if you get a chance. - Brian On 8/7/06, Stephen Sinclair <rad...@gm...> wrote: > > This is the new LoopDub developer mailing list! Currently with a > grand total of 2 members! > Sorry, I didn't notice that it was set up already because the > preferences weren't configured properly. :) > > (Therefore, this message is just partially a test of the listserv. > Never administered one before, so hopefully it will work. Cross your > fingers..) > > > Just for archival purposes I'll mention a few points in 3rd person > english: > > Brian & Steve have been talking about improvements to LoopDub. He > suggests creating some tools to allow dynamic loop stretching using > the SoundTouch library. > > Steve said: "Some priorities right now for me are to work on the MIDI > clock output so I can use it with my drum machine, and also get the > Windows and OS X binaries distributed... that's sure to make it more > interesting for a lot of people! Also.. the issue of it using far too > much memory." > > This let to a short discussion on memory pools and how something like > that would be benificial instead of allocating and deallocating memory > all the time. > > Perhaps I'll post more parts of the discussion later, but more > interesting ideas will certainly emerge as time goes on. > > > Steve > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Loopdub-devel mailing list > Loo...@li... > https://lists.sourceforge.net/lists/listinfo/loopdub-devel > |
From: Stephen S. <rad...@gm...> - 2006-08-07 15:26:50
|
This is the new LoopDub developer mailing list! Currently with a grand total of 2 members! Sorry, I didn't notice that it was set up already because the preferences weren't configured properly. :) (Therefore, this message is just partially a test of the listserv. Never administered one before, so hopefully it will work. Cross your fingers..) Just for archival purposes I'll mention a few points in 3rd person english: Brian & Steve have been talking about improvements to LoopDub. He suggests creating some tools to allow dynamic loop stretching using the SoundTouch library. Steve said: "Some priorities right now for me are to work on the MIDI clock output so I can use it with my drum machine, and also get the Windows and OS X binaries distributed... that's sure to make it more interesting for a lot of people! Also.. the issue of it using far too much memory." This let to a short discussion on memory pools and how something like that would be benificial instead of allocating and deallocating memory all the time. Perhaps I'll post more parts of the discussion later, but more interesting ideas will certainly emerge as time goes on. Steve |