As with your previous mails, I've read today's mail with interest.
In the absence of a deeper, more elegant and more sweeping change of the
storage server, can I ask a dumb question?
You know there is a mass import script for the import of entire
directories, right? It's in the /opt/campcaster/bin directory, and with
the -d directive, you can import an entire directory (including
recursively).
The command would look like:
cd /opt/campcaster/bin/
sudo ./import.sh -d /path/to/your/files
Then it will go out and grab all the files in that directory. It's
inelegant and needs some love, but at least it will save you the trouble
of importing files one by one.
What I do is to create a desktop launcher on the Ubuntu desktop, so that
users can simply drag and drop their directories on to the launcher item,
which starts the script and handles the input. If things are quiet enough
for me this week, I'll put up a howto for doing that, but it's really
straightforward.
The use case scenario we've been working with was that when a station
decides to make the switch to Campcaster, one of the prepatory steps would
be to run that script to get enough material into the Storage Server.
Then, as additional files or directories added, either the import script
or the UI could work.
I'm with you on the serious need for support for 'smart playlists' in
Campcaster, and we would seriously welcome some help in getting that
functionality going.
My .02,
douglas
=============================================
Media Development Loan Fund
=============================================
Douglas Arellanes
Head of Research and Development
Center for Advanced Media--Prague (CAMP)
Na vinicnich horach 24a/1834, 160 00 Prague 6
Czech Republic
Tel: + 420 2 3333 5356, Fax: +420 2 2431 5419
Mobile: +420 724 073 364 http://www.mdlf-camp.net http://www.campware.org
============================================= http://www.mdlf.org
=============================================
"sawyer x"
01/07/2007 06:00 PM
Please respond to campcaster-dev
On 1/7/07, Pierre-Luc wrote:
"when i read all the discussion here i doubt whether the import is
really the problem, but i can't imagine how someone could work with
campcaster when they can't import a folder right, and have to upload
song by song in the UI, not to mention having to wait for track copy
to be made whenever wanting to add a broadcast (which is 1 hour at
least - which means it could take up to 100MB or more) in order to
play it at a specific time. "
With most radio automation software I have seen from now, you have do
to so (waiting for track copy to be made)... Campcaster isn't just a
"music player" as Rhythmbox or Amarok are after all. But I agree to
that it could be harder to prepare your programming without the random
play functionality.
2007/1/7, sawyer x :
> hey everyone
>
> i know i'm not a developer on the team and so i obviously don't
> see/understand these things the way you do, but
> the radio station i'm a part of could not work with campcaster, because
it
> failed to supply a comfortable/easy (or even suffice) solution for
uploading
> the programs we're running and providing the live broadcasters to upload
a
> whole folder of their songs into the scratch pad to be used while in
live
> mode. not to even mention being able to import the station songs to the
> library and be able to random (or even without random) play the songs
when
> not having scheduled shows.
>
> that's why i found the import to be the main issue - because we failed
at
> being able to _use_ campcaster at all because of it.
>
> when i read all the discussion here i doubt whether the import is really
the
> problem, but i can't imagine how someone could work with campcaster when
> they can't import a folder right, and have to upload song by song in the
UI,
> not to mention having to wait for track copy to be made whenever wanting
to
> add a broadcast (which is 1 hour at least - which means it could take up
to
> 100MB or more) in order to play it at a specific time.
>
> i've tried to look for explanation in the documentation online, but
failed
> to see why some people are apparently able to work with campcaster and
my
> station can't.
>
> i would be mighty thankful if anyone could correct me on this and show
me
> what we're doing wrong. i know caring for my BS isn't a top (or even
minor)
> priority for campcaster but it is really important to us, since
campcaster
> seems like the solution we want and the only thing that bothers us is
the
> importing our recordings (songs, shows) into the library/scratchpad.
even
> the issues you all raised (which you know more about than i do) don't
bother
> us. we're at a desperate point, really.
>
> thanks for reading/listening and sorry for the bitching and long email.
>
> best regards,
> sawyer.
>
>
> On 1/6/07, Paul Baranowski < paulbaranowski@gmail.com> wrote:
> > Great ideas Ferenc. As you pointed out, both ideas are compatible
with
> > each other. I'll start a wiki page with these proposals.
> >
> >
> > Ferenc Gerlits wrote:
> > > Hi Paul,
> > >
> > > I think we could make Studio into a usable Live Assist system with
> > > relatively minor changes. It would be a huge waste to stop now,
start
> > > over from scratch, and spend months on a complete redesign. These
are
> > > the minor changes I have in mind:
> > >
> > > Usage scenario:
> > >
> > > 1. The audio technician opens a file browser to a USB stick or a
network
> > > drive, selects the files prepared by the journalists, and drops them
on
> > > a desktop shortcut for the Mass Import script.
> > >
> > > 2. He starts up Studio, which opens the sub-windows to the
configuration
> > > in which he left them the previous day.
> > >
> > > 3a. The Search window has an option for searching for files added
> > > recently. He finds the files he just added, and drags them over to
the
> > > Live Mode window.
> > >
> > > 3b. Optionally: searches for some more files, and adds these to the
Live
> > > Mode window as well.
> > >
> > > 3c. He adds some jingles from the Scratchpad to the Live Mode
Window.
> > >
> > > 4. He rearranges the files in the Live Mode window to the correct
order;
> > > marks some of them as "beds", ie, background sounds which will loop
> > > continuously when played.
> > >
> > > 5. He presses a (customizable) key to start playing the top item in
the
> > > Live Mode Window; this key would do this no matter which window is
> > > selected. He can also double-click an item possibly different from
the
> > > top one, to play it out of order.
> > >
> > > 6. He logs out, exits Studio, exits the studio, and goes home.
> > >
> > > The changes we'd need to implement for this are the following:
> > >
> > > * Modify the mass import script to accept directories and files
mixed
> > > together (at the moment, you have to specify -f or -d).
> > >
> > > * Remember the open/closed state of windows at logout.
> > >
> > > * Implement a "search for recently added" feature in the Search
> window.
> > >
> > > * Implement drag and drop between Studio windows.
> > >
> > > * Forget the idea that everything touched goes to the Scratchpad
> > > window, and use it as a jingle bank instead.
> > >
> > > * Add an Automatic/Manual switch to the Live Mode window.
> > >
> > > * Implement a global hotkey which activates the Play button in the
> > > Live Mode window.
> > >
> > > These are all small changes which can be done in the next weeks,
instead
> > > of months, and would noticeably improve the usability.
> > >
> > > After this, there are (bigger) second tier features we can do:
> > >
> > > * Allow for mass import directly into Studio.
> > >
> > > * Implement an audio properties pop-up window for displaying
(possibly
> > > editing) metadata.
> > >
> > > * Integrate the Scheduler into Studio, including a nicer Scheduler
> > > window, with day view.
> > >
> > > * Grey out instead of remove played items in the Live Mode window,
and
> > > allow the contents to be saved as a playlist metafile.
> > >
> > > * Support for web stream inputs.
> > >
> > > * Support for streaming the output to a web stream.
> > >
> > > * Allow the user to save his user name, password and preferred
> > > language, so in a single-user setting he wouldn't have to log in
every
> > > time he starts Studio.
> > >
> > > * etc
> > >
> > > Completely redesigning the interface to make it single-windowed, in
my
> > > mind, comes somewhere way down the list, after all of the above are
> > > finished. Having said that, I _would_ like to rewrite Studio in
> > > libglade: that would mean separating the code from the visual
design, so
> > > it would allow creative people to redraw windows (change color,
spacing,
> > > placement of widgets) without any change in the C++ code. That
would be
> > > a good thing, and I hope Sava can find the budget for it, but it
> > > probably won't be easy.
> > >
> > > Ferenc
> > >
> > >
> >
>
>
we've tried the mass import script but had a few problems with it.
the main issues were that it took a very long time to copy everything (well,
it's a lot of GBs so it makes perfect sense) and that because it would make
copies, it would fill up our HDs. of course we can't have that.
i started writing a script (with a lot of help from different devs - thanks
btw) but wasn't able to implement it because i got too confused with the
structure of the storing process. also, i tried hacking the php script to
remove the actual line where it copies and replace that with a small script
that would create the proper symlinks instead but .. alas, i wasn't able to
pinpoint the exact location of the php copy() command.
i think if i could do these two, you would get a lot less bitching coming
from us hehe..
our radio station is formed by anarchists and alike, and we're _all_ for
helping in any way we can.
i would love to help but to do that, i'll need assistance to understand how
campcaster's internals works..
best regards,
sawyer.
On 1/7/07, Douglas.Arellanes@mdlf.org wrote:
>
>
> Hi Sawyer,
>
>
> As with your previous mails, I've read today's mail with interest.
>
> In the absence of a deeper, more elegant and more sweeping change of the
> storage server, can I ask a dumb question?
>
> You know there is a mass import script for the import of entire
> directories, right? It's in the /opt/campcaster/bin directory, and with the
> -d directive, you can import an entire directory (including recursively).
>
> The command would look like:
>
> cd /opt/campcaster/bin/
> sudo ./import.sh -d /path/to/your/files
>
> Then it will go out and grab all the files in that directory. It's
> inelegant and needs some love, but at least it will save you the trouble of
> importing files one by one.
>
> What I do is to create a desktop launcher on the Ubuntu desktop, so that
> users can simply drag and drop their directories on to the launcher item,
> which starts the script and handles the input. If things are quiet enough
> for me this week, I'll put up a howto for doing that, but it's really
> straightforward.
>
> The use case scenario we've been working with was that when a station
> decides to make the switch to Campcaster, one of the prepatory steps would
> be to run that script to get enough material into the Storage Server. Then,
> as additional files or directories added, either the import script or the UI
> could work.
>
> I'm with you on the serious need for support for 'smart playlists' in
> Campcaster, and we would seriously welcome some help in getting that
> functionality going.
>
>
> My .02,
>
>
> douglas
>
>
> =============================================
> Media Development Loan Fund
> =============================================
> Douglas Arellanes
> Head of Research and Development
> Center for Advanced Media--Prague (CAMP)
> Na vinicnich horach 24a/1834, 160 00 Prague 6
> Czech Republic
> Tel: + 420 2 3333 5356, Fax: +420 2 2431 5419
> Mobile: +420 724 073 364
> http://www.mdlf-camp.net
> http://www.campware.org
> =============================================
> http://www.mdlf.org
> =============================================
>
>
>
> *"sawyer x" *
>
> 01/07/2007 06:00 PM
> Please respond to campcaster-dev
>
> To: campcaster-dev@campware.org
> cc:
> Subject: Re: [campcaster-dev] Studio Redesign
>
>
> are we doing anything wrong?
>
>
> On 1/7/07, *Pierre-Luc* <*pierrelucbacon@gmail.com*>
> wrote:
> "when i read all the discussion here i doubt whether the import is
> really the problem, but i can't imagine how someone could work with
> campcaster when they can't import a folder right, and have to upload
> song by song in the UI, not to mention having to wait for track copy
> to be made whenever wanting to add a broadcast (which is 1 hour at
> least - which means it could take up to 100MB or more) in order to
> play it at a specific time. "
>
> With most radio automation software I have seen from now, you have do
> to so (waiting for track copy to be made)... Campcaster isn't just a
> "music player" as Rhythmbox or Amarok are after all. But I agree to
> that it could be harder to prepare your programming without the random
> play functionality.
>
> 2007/1/7, sawyer x <*xsawyerx@gmail.com* >:
> > hey everyone
> >
> > i know i'm not a developer on the team and so i obviously don't
> > see/understand these things the way you do, but
> > the radio station i'm a part of could not work with campcaster, because
> it
> > failed to supply a comfortable/easy (or even suffice) solution for
> uploading
> > the programs we're running and providing the live broadcasters to upload
> a
> > whole folder of their songs into the scratch pad to be used while in
> live
> > mode. not to even mention being able to import the station songs to the
> > library and be able to random (or even without random) play the songs
> when
> > not having scheduled shows.
> >
> > that's why i found the import to be the main issue - because we failed
> at
> > being able to _use_ campcaster at all because of it.
> >
> > when i read all the discussion here i doubt whether the import is really
> the
> > problem, but i can't imagine how someone could work with campcaster when
>
> > they can't import a folder right, and have to upload song by song in the
> UI,
> > not to mention having to wait for track copy to be made whenever wanting
> to
> > add a broadcast (which is 1 hour at least - which means it could take up
> to
> > 100MB or more) in order to play it at a specific time.
> >
> > i've tried to look for explanation in the documentation online, but
> failed
> > to see why some people are apparently able to work with campcaster and
> my
> > station can't.
> >
> > i would be mighty thankful if anyone could correct me on this and show
> me
> > what we're doing wrong. i know caring for my BS isn't a top (or even
> minor)
> > priority for campcaster but it is really important to us, since
> campcaster
> > seems like the solution we want and the only thing that bothers us is
> the
> > importing our recordings (songs, shows) into the library/scratchpad.
> even
> > the issues you all raised (which you know more about than i do) don't
> bother
> > us. we're at a desperate point, really.
> >
> > thanks for reading/listening and sorry for the bitching and long email.
> >
> > best regards,
> > sawyer.
> >
> >
> > On 1/6/07, Paul Baranowski < *paulbaranowski@gmail.com*>
> wrote:
> > > Great ideas Ferenc. As you pointed out, both ideas are compatible
> with
> > > each other. I'll start a wiki page with these proposals.
> > >
> > >
> > > Ferenc Gerlits wrote:
> > > > Hi Paul,
> > > >
> > > > I think we could make Studio into a usable Live Assist system with
> > > > relatively minor changes. It would be a huge waste to stop now,
> start
> > > > over from scratch, and spend months on a complete redesign. These
> are
> > > > the minor changes I have in mind:
> > > >
> > > > Usage scenario:
> > > >
> > > > 1. The audio technician opens a file browser to a USB stick or a
> network
> > > > drive, selects the files prepared by the journalists, and drops them
> on
> > > > a desktop shortcut for the Mass Import script.
> > > >
> > > > 2. He starts up Studio, which opens the sub-windows to the
> configuration
> > > > in which he left them the previous day.
> > > >
> > > > 3a. The Search window has an option for searching for files added
> > > > recently. He finds the files he just added, and drags them over to
> the
> > > > Live Mode window.
> > > >
> > > > 3b. Optionally: searches for some more files, and adds these to the
> Live
> > > > Mode window as well.
> > > >
> > > > 3c. He adds some jingles from the Scratchpad to the Live Mode
> Window.
> > > >
> > > > 4. He rearranges the files in the Live Mode window to the correct
> order;
> > > > marks some of them as "beds", ie, background sounds which will loop
> > > > continuously when played.
> > > >
> > > > 5. He presses a (customizable) key to start playing the top item in
> the
> > > > Live Mode Window; this key would do this no matter which window is
> > > > selected. He can also double-click an item possibly different from
> the
> > > > top one, to play it out of order.
> > > >
> > > > 6. He logs out, exits Studio, exits the studio, and goes home.
> > > >
> > > > The changes we'd need to implement for this are the following:
> > > >
> > > > * Modify the mass import script to accept directories and files
> mixed
> > > > together (at the moment, you have to specify -f or -d).
> > > >
> > > > * Remember the open/closed state of windows at logout.
> > > >
> > > > * Implement a "search for recently added" feature in the Search
> > window.
> > > >
> > > > * Implement drag and drop between Studio windows.
> > > >
> > > > * Forget the idea that everything touched goes to the Scratchpad
> > > > window, and use it as a jingle bank instead.
> > > >
> > > > * Add an Automatic/Manual switch to the Live Mode window.
> > > >
> > > > * Implement a global hotkey which activates the Play button in the
> > > > Live Mode window.
> > > >
> > > > These are all small changes which can be done in the next weeks,
> instead
> > > > of months, and would noticeably improve the usability.
> > > >
> > > > After this, there are (bigger) second tier features we can do:
> > > >
> > > > * Allow for mass import directly into Studio.
> > > >
> > > > * Implement an audio properties pop-up window for displaying
> (possibly
> > > > editing) metadata.
> > > >
> > > > * Integrate the Scheduler into Studio, including a nicer Scheduler
>
> > > > window, with day view.
> > > >
> > > > * Grey out instead of remove played items in the Live Mode window,
> and
> > > > allow the contents to be saved as a playlist metafile.
> > > >
> > > > * Support for web stream inputs.
> > > >
> > > > * Support for streaming the output to a web stream.
> > > >
> > > > * Allow the user to save his user name, password and preferred
> > > > language, so in a single-user setting he wouldn't have to log in
> every
> > > > time he starts Studio.
> > > >
> > > > * etc
> > > >
> > > > Completely redesigning the interface to make it single-windowed, in
> my
> > > > mind, comes somewhere way down the list, after all of the above are
> > > > finished. Having said that, I _would_ like to rewrite Studio in
> > > > libglade: that would mean separating the code from the visual
> design, so
> > > > it would allow creative people to redraw windows (change color,
> spacing,
> > > > placement of widgets) without any change in the C++ code. That
> would be
> > > > a good thing, and I hope Sava can find the budget for it, but it
> > > > probably won't be easy.
> > > >
> > > > Ferenc
> > > >
> > > >
> > >
> >
> >
>
>
> --
> Pierre-Luc Bacon*
> **www.aqra.ca*
>
>
>
We are listening to you, and we agree that those are major problems.
With Campcaster 1.1 we just wanted something that worked (i.e. didnt
crash), and now we want start to make it more elegant. Those problems
you mention will be fixed in the next release of Campcaster which should
be out next month. If you want to get your hands wet with PHP, we could
use your help. I myself am learning the code as well as I was not one
of the people who originally developed it. Currently I am working on
preventing "double import" problem, after that I will be working on the
"double disk usage" problem.
The studio redesign discussion was a look to the somewhat farther
future, stuff that would start to come after this next release.
- Paul
sawyer x wrote:
> thanks for the thoughtful reply.
>
> we've tried the mass import script but had a few problems with it.
> the main issues were that it took a very long time to copy everything (well,
> it's a lot of GBs so it makes perfect sense) and that because it would make
> copies, it would fill up our HDs. of course we can't have that.
>
> i started writing a script (with a lot of help from different devs - thanks
> btw) but wasn't able to implement it because i got too confused with the
> structure of the storing process. also, i tried hacking the php script to
> remove the actual line where it copies and replace that with a small script
> that would create the proper symlinks instead but .. alas, i wasn't able to
> pinpoint the exact location of the php copy() command.
> i think if i could do these two, you would get a lot less bitching coming
> from us hehe..
>
> our radio station is formed by anarchists and alike, and we're _all_ for
> helping in any way we can.
> i would love to help but to do that, i'll need assistance to understand how
> campcaster's internals works..
>
> best regards,
> sawyer.
>
> On 1/7/07, Douglas.Arellanes@mdlf.org wrote:
>>
>> Hi Sawyer,
>>
>>
>> As with your previous mails, I've read today's mail with interest.
>>
>> In the absence of a deeper, more elegant and more sweeping change of the
>> storage server, can I ask a dumb question?
>>
>> You know there is a mass import script for the import of entire
>> directories, right? It's in the /opt/campcaster/bin directory, and with the
>> -d directive, you can import an entire directory (including recursively).
>>
>> The command would look like:
>>
>> cd /opt/campcaster/bin/
>> sudo ./import.sh -d /path/to/your/files
>>
>> Then it will go out and grab all the files in that directory. It's
>> inelegant and needs some love, but at least it will save you the trouble of
>> importing files one by one.
>>
>> What I do is to create a desktop launcher on the Ubuntu desktop, so that
>> users can simply drag and drop their directories on to the launcher item,
>> which starts the script and handles the input. If things are quiet enough
>> for me this week, I'll put up a howto for doing that, but it's really
>> straightforward.
>>
>> The use case scenario we've been working with was that when a station
>> decides to make the switch to Campcaster, one of the prepatory steps would
>> be to run that script to get enough material into the Storage Server. Then,
>> as additional files or directories added, either the import script or the UI
>> could work.
>>
>> I'm with you on the serious need for support for 'smart playlists' in
>> Campcaster, and we would seriously welcome some help in getting that
>> functionality going.
>>
>>
>> My .02,
>>
>>
>> douglas
>>
>>
>> =============================================
>> Media Development Loan Fund
>> =============================================
>> Douglas Arellanes
>> Head of Research and Development
>> Center for Advanced Media--Prague (CAMP)
>> Na vinicnich horach 24a/1834, 160 00 Prague 6
>> Czech Republic
>> Tel: + 420 2 3333 5356, Fax: +420 2 2431 5419
>> Mobile: +420 724 073 364
>> http://www.mdlf-camp.net
>> http://www.campware.org
>> =============================================
>> http://www.mdlf.org
>> =============================================
>>
>>
>>
>> *"sawyer x" *
>>
>> 01/07/2007 06:00 PM
>> Please respond to campcaster-dev
>>
>> To: campcaster-dev@campware.org
>> cc:
>> Subject: Re: [campcaster-dev] Studio Redesign
>>
>>
>> are we doing anything wrong?
>>
>>
>> On 1/7/07, *Pierre-Luc* <*pierrelucbacon@gmail.com*>
>> wrote:
>> "when i read all the discussion here i doubt whether the import is
>> really the problem, but i can't imagine how someone could work with
>> campcaster when they can't import a folder right, and have to upload
>> song by song in the UI, not to mention having to wait for track copy
>> to be made whenever wanting to add a broadcast (which is 1 hour at
>> least - which means it could take up to 100MB or more) in order to
>> play it at a specific time. "
>>
>> With most radio automation software I have seen from now, you have do
>> to so (waiting for track copy to be made)... Campcaster isn't just a
>> "music player" as Rhythmbox or Amarok are after all. But I agree to
>> that it could be harder to prepare your programming without the random
>> play functionality.
>>
>> 2007/1/7, sawyer x <*xsawyerx@gmail.com* >:
>>> hey everyone
>>>
>>> i know i'm not a developer on the team and so i obviously don't
>>> see/understand these things the way you do, but
>>> the radio station i'm a part of could not work with campcaster, because
>> it
>>> failed to supply a comfortable/easy (or even suffice) solution for
>> uploading
>>> the programs we're running and providing the live broadcasters to upload
>> a
>>> whole folder of their songs into the scratch pad to be used while in
>> live
>>> mode. not to even mention being able to import the station songs to the
>>> library and be able to random (or even without random) play the songs
>> when
>>> not having scheduled shows.
>>>
>>> that's why i found the import to be the main issue - because we failed
>> at
>>> being able to _use_ campcaster at all because of it.
>>>
>>> when i read all the discussion here i doubt whether the import is really
>> the
>>> problem, but i can't imagine how someone could work with campcaster when
>>> they can't import a folder right, and have to upload song by song in the
>> UI,
>>> not to mention having to wait for track copy to be made whenever wanting
>> to
>>> add a broadcast (which is 1 hour at least - which means it could take up
>> to
>>> 100MB or more) in order to play it at a specific time.
>>>
>>> i've tried to look for explanation in the documentation online, but
>> failed
>>> to see why some people are apparently able to work with campcaster and
>> my
>>> station can't.
>>>
>>> i would be mighty thankful if anyone could correct me on this and show
>> me
>>> what we're doing wrong. i know caring for my BS isn't a top (or even
>> minor)
>>> priority for campcaster but it is really important to us, since
>> campcaster
>>> seems like the solution we want and the only thing that bothers us is
>> the
>>> importing our recordings (songs, shows) into the library/scratchpad.
>> even
>>> the issues you all raised (which you know more about than i do) don't
>> bother
>>> us. we're at a desperate point, really.
>>>
>>> thanks for reading/listening and sorry for the bitching and long email.
>>>
>>> best regards,
>>> sawyer.
>>>
>>>
>>> On 1/6/07, Paul Baranowski < *paulbaranowski@gmail.com*>
>> wrote:
>>>> Great ideas Ferenc. As you pointed out, both ideas are compatible
>> with
>>>> each other. I'll start a wiki page with these proposals.
>>>>
>>>>
>>>> Ferenc Gerlits wrote:
>>>>> Hi Paul,
>>>>>
>>>>> I think we could make Studio into a usable Live Assist system with
>>>>> relatively minor changes. It would be a huge waste to stop now,
>> start
>>>>> over from scratch, and spend months on a complete redesign. These
>> are
>>>>> the minor changes I have in mind:
>>>>>
>>>>> Usage scenario:
>>>>>
>>>>> 1. The audio technician opens a file browser to a USB stick or a
>> network
>>>>> drive, selects the files prepared by the journalists, and drops them
>> on
>>>>> a desktop shortcut for the Mass Import script.
>>>>>
>>>>> 2. He starts up Studio, which opens the sub-windows to the
>> configuration
>>>>> in which he left them the previous day.
>>>>>
>>>>> 3a. The Search window has an option for searching for files added
>>>>> recently. He finds the files he just added, and drags them over to
>> the
>>>>> Live Mode window.
>>>>>
>>>>> 3b. Optionally: searches for some more files, and adds these to the
>> Live
>>>>> Mode window as well.
>>>>>
>>>>> 3c. He adds some jingles from the Scratchpad to the Live Mode
>> Window.
>>>>> 4. He rearranges the files in the Live Mode window to the correct
>> order;
>>>>> marks some of them as "beds", ie, background sounds which will loop
>>>>> continuously when played.
>>>>>
>>>>> 5. He presses a (customizable) key to start playing the top item in
>> the
>>>>> Live Mode Window; this key would do this no matter which window is
>>>>> selected. He can also double-click an item possibly different from
>> the
>>>>> top one, to play it out of order.
>>>>>
>>>>> 6. He logs out, exits Studio, exits the studio, and goes home.
>>>>>
>>>>> The changes we'd need to implement for this are the following:
>>>>>
>>>>> * Modify the mass import script to accept directories and files
>> mixed
>>>>> together (at the moment, you have to specify -f or -d).
>>>>>
>>>>> * Remember the open/closed state of windows at logout.
>>>>>
>>>>> * Implement a "search for recently added" feature in the Search
>>> window.
>>>>> * Implement drag and drop between Studio windows.
>>>>>
>>>>> * Forget the idea that everything touched goes to the Scratchpad
>>>>> window, and use it as a jingle bank instead.
>>>>>
>>>>> * Add an Automatic/Manual switch to the Live Mode window.
>>>>>
>>>>> * Implement a global hotkey which activates the Play button in the
>>>>> Live Mode window.
>>>>>
>>>>> These are all small changes which can be done in the next weeks,
>> instead
>>>>> of months, and would noticeably improve the usability.
>>>>>
>>>>> After this, there are (bigger) second tier features we can do:
>>>>>
>>>>> * Allow for mass import directly into Studio.
>>>>>
>>>>> * Implement an audio properties pop-up window for displaying
>> (possibly
>>>>> editing) metadata.
>>>>>
>>>>> * Integrate the Scheduler into Studio, including a nicer Scheduler
>>>>> window, with day view.
>>>>>
>>>>> * Grey out instead of remove played items in the Live Mode window,
>> and
>>>>> allow the contents to be saved as a playlist metafile.
>>>>>
>>>>> * Support for web stream inputs.
>>>>>
>>>>> * Support for streaming the output to a web stream.
>>>>>
>>>>> * Allow the user to save his user name, password and preferred
>>>>> language, so in a single-user setting he wouldn't have to log in
>> every
>>>>> time he starts Studio.
>>>>>
>>>>> * etc
>>>>>
>>>>> Completely redesigning the interface to make it single-windowed, in
>> my
>>>>> mind, comes somewhere way down the list, after all of the above are
>>>>> finished. Having said that, I _would_ like to rewrite Studio in
>>>>> libglade: that would mean separating the code from the visual
>> design, so
>>>>> it would allow creative people to redraw windows (change color,
>> spacing,
>>>>> placement of widgets) without any change in the C++ code. That
>> would be
>>>>> a good thing, and I hope Sava can find the budget for it, but it
>>>>> probably won't be easy.
>>>>>
>>>>> Ferenc
>>>>>
>>>>>
>>>
>>
>> --
>> Pierre-Luc Bacon*
>> **www.aqra.ca*
>>
>>
>>
>
On Sun, 2007-01-07 at 19:43 +0200, sawyer x wrote:
> thanks for the thoughtful reply.
>
> we've tried the mass import script but had a few problems with it.
> the main issues were that it took a very long time to copy everything
> (well, it's a lot of GBs so it makes perfect sense) and that because
> it would make copies, it would fill up our HDs. of course we can't
> have that.
>
> i started writing a script (with a lot of help from different devs -
> thanks btw) but wasn't able to implement it because i got too confused
> with the structure of the storing process. also, i tried hacking the
> php script to remove the actual line where it copies and replace that
> with a small script that would create the proper symlinks instead
> but .. alas, i wasn't able to pinpoint the exact location of the php
> copy() command.
> i think if i could do these two, you would get a lot less bitching
> coming from us hehe..
>
> our radio station is formed by anarchists and alike, and we're _all_
> for helping in any way we can.
> i would love to help but to do that, i'll need assistance to
> understand how campcaster's internals works..
>
> best regards,
> sawyer.