Well, i would say that Amazon is good for business, because of abilities
to get more, but for FOSS project it's not. That's why i've proposed git
first - there's a 1GB limit for projects, if download into git
!=samples, then for presets it will be enough place and open music
projects can go int
2014-05-02 8:43 GMT+02:00 Tres Finocchiaro :
> There's not even any code in LSP2
There once was, written by Toby. Jonathan removed it, I guess only he knows
why. (It wasn't much code though, but all the necessary models were there)
I'm officially pulling myself off of these LSP discussions. This last
email was the last straw, my time is spent wiser working on other aspects
of the project.
- tres.finocchi...@gmail.com
On Fri, May 2, 2014 at 2:12 AM, Jonathan Aquilina wrote:
> I have another idea on a cloud solution but we
At this point I see absolutely no purpose in hiding bug reports away in a
code repository we may not even use. There's not even any code in LSP2, it
should be deleted until a dedicated home is warranted.
I don't understand your logic.
I see TODO list out there:
- New theme (try for simpler Goo
Nothing wrong, I think we need to at least in terms of the cloud concept
have that on the lsp tracker as well as its not only integrating it wiht
lmms itself but integration into lsp.
On Fri, May 2, 2014 at 8:13 AM, Tres Finocchiaro wrote:
> 1) collaborato: integration of AWS into the sharing
I have another idea on a cloud solution but we are not limited on IO
requests or bandwidth per se here.
I am not being biased here. I am thinking the following.
a vps from https://www.linode.com/pricing in particular the entry level vps.
Then on that vps we would setup own cloud http://owncloud.
>
> 1) collaborato: integration of AWS into the sharing platform
>
What's wrong with this one? https://github.com/LMMS/lmms/issues/661
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run
Hey guys I am going to file some of these ideas in the LSP issue tracker.
1) collaborato: integration of AWS into the sharing platform
2) integration of LSP into CMS
Is there anything else that I am potentially missing?
--
Jonathan Aquilina
-
*note, this assumes the storage increases at the same rate as the bandwidth
which may never be the case, so prob safe to make the 10 mil closer to $35
and the 100mil closer to $350.
--
"Accelerate Dev Cycles with Automated
Great thanks Lukas.
So here are some figures. Note, these are just ballpark figures.
*1,000,000 request/month: **500MB storage, 26GB bandwidth, *
- Bandwidth: $3/month
- IO: $0.40/month
- Storage: $1.00/month
- *Total: About $5/month (1 Million requests/month)*
*10,000,000 downl
Oh, note that this is only counting the files that did not get deleted.
2014-05-01 20:33 GMT+02:00 Lukas W. :
> Nevermind, I managed to access the db. It took me quite some time to get
> the data, as the phpmyadmin interface on SF really is *horribly* slow.
> Using SQL queries, I get a total num
Nevermind, I managed to access the db. It took me quite some time to get
the data, as the phpmyadmin interface on SF really is *horribly* slow.
Using SQL queries, I get a total number of 4021 files, summing up to 348Mib
in size. I don't know where those 1339 extra files on FTP come from, I
guess fi
On Thu, May 1, 2014 at 1:46 PM, Lukas W. wrote:
> You mean the size of the shared files in the current LSP? As far as I can
> see, those are 519MiB (or 544MB) counting 5360 files at the moment.
>
Fantastic, thank you.
> I can't say anything about the download counts, as I still have no admin
You mean the size of the shared files in the current LSP? As far as I can
see, those are 519MiB (or 544MB) counting 5360 files at the moment.
I can't say anything about the download counts, as I still have no admin
rights and therefore can't access the SQL database.
2014-05-01 15:38 GMT+02:00 Tr
@Lukas,
Do you have the ability to measure the approx LSP overall size (I mean the
actual shared files)?
I'd like to document how much space we're using and get at least a ballpark
for storage requirements if it were to expand for 5 years.
Also (this one is a stretch) but there is a "popularity"
I was actually just thinking about that. Is there someone that can work on
making the code RT-safe? Do we have any goals as to when we want RTS code
by?
On Tue, Apr 29, 2014 at 8:32 PM, Vesa wrote:
> On 04/29/2014 03:52 PM, Jonathan Aquilina wrote:
> > I agree uploads at this point should not b
Note that the "Free Tier" on AWS is only offered for the first 12 months.
2014-04-30 4:28 GMT+02:00 Tres Finocchiaro :
> So I'm looking into a proper cloud storage for "collaborato" :) and I've
> come across a few options (please list any/all others).
>
>- *Google Cloud Storage*
>- *Amaz
Toby, This is something that I think should not be rushed. I think this
feature for 2.0 does seam reasonable.
On Tue, Apr 29, 2014 at 11:54 PM, Tobias Doerffel wrote:
> 2014-04-29 20:41 GMT+02:00 Vesa :
> > So.. How would this work in practice? Do you mean that the sidebar tabs
> > would be con
Looking at the api's One thing that i find very interesting is the NFS/CIFS
(samba) protocols that EMC support. With a vpn connection one coudl easily
and securly connect to the cloud storage to access the files.
What worries me about Google and amazon they seem like they would get
pricey rather q
So I'm looking into a proper cloud storage for "collaborato" :) and I've
come across a few options (please list any/all others).
- *Google Cloud Storage*
- *Amazon S3*
- *EMC Atmos*
Feel free to read the details below, but my initial analysis is to use
Amazon since they offer a "Free Tie
2014-04-29 20:41 GMT+02:00 Vesa :
> So.. How would this work in practice? Do you mean that the sidebar tabs
> would be configurable? Where would this configuration be done... would
> there be an "add tab" button, and context menus for each tab to remove
> them? Or would the configuration be done in
Disagree. Online would be supercool as it is annoying constantly having to
copy presets to the right folder.
diiz wrote
> On 04/28/2014 10:47 PM, Tobias Doerffel wrote:
>
> I really think we should wait and think about this before merging this.
>
> I remember trying this feature on the old mast
On 04/29/2014 05:18 PM, Tobias Doerffel wrote:
> @Vesa: the resource framework including UI is completely flexible. You
> can still have arbitrary tabs and "mount" whatever local or remote
> resource DB wherever you want (it's a model/view architecture based on
> Qt's model view architecture). It w
On 04/29/2014 03:52 PM, Jonathan Aquilina wrote:
> I agree uploads at this point should not be done via lmms. LMMS is
> already as complex as it is. It will be getting more complex as we
> move towards real time safe code with paul's unison core.
>
Offtopic, but: let's stop talking about "when we
On Tue, Apr 29, 2014 at 10:39 AM, Jonathan Aquilina
wrote:
> Having them in requests will allow it to be kept track of and easier for
> me to prioritize what needs to be done.
>
Agreed. At this point, we should be discussing this on two cross-linked
bug reports. One for LSP and another for Coll
What was proposed with version control. I think that is why I mentioned
alfresco it provides versioning. I will step back on this at this point.
On Tue, Apr 29, 2014 at 4:13 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> These ideas aren't all relevant to LSP2. They should instead
Having them in requests will allow it to be kept track of and easier for me
to prioritize what needs to be done.
On Tue, Apr 29, 2014 at 4:36 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
>
> On Tue, Apr 29, 2014 at 10:18 AM, Tobias Doerffel <
> tobias.doerf...@gmail.com> wrote:
>
>>
On Tue, Apr 29, 2014 at 10:18 AM, Tobias Doerffel wrote:
> 2014-04-29 16:13 GMT+02:00 Tres Finocchiaro :
> > These ideas aren't **all** relevant to LSP2. They should instead be in
> an LMMS
> > enhancement request.
>
> They are because you need to have a future API in mind that we can use
> in L
2014-04-29 16:13 GMT+02:00 Tres Finocchiaro :
> These ideas aren't all relevant to LSP2. They should instead be in an LMMS
> enhancement request.
They are because you need to have a future API in mind that we can use
in LMMS. Hacking in web resources later is more work (I experienced
that a few y
These ideas aren't all relevant to LSP2. They should instead be in an LMMS
enhancement request.
I'm still confused as to the purpose of the LSP2 area since its all up on
the air at this point. And your recommendations for Alfresco are way off
in left field. Let's please not yet propose yet anot
Is it possible to get these ideas filed on the LSP2 issue tracker please.
On Tue, Apr 29, 2014 at 2:44 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> This discussion is going off in quite a few directions. Some arguments
> are concerned with UI design. Some are concerned with UI r
I agree uploads at this point should not be done via lmms. LMMS is already
as complex as it is. It will be getting more complex as we move towards
real time safe code with paul's unison core.
On Tue, Apr 29, 2014 at 2:48 PM, Vesa wrote:
> On 04/29/2014 03:44 PM, Tres Finocchiaro wrote:
> > This
I can offer space on my cloud storage provider they have an api and we
could interface it with that actually, and there I have a total of 5TB of
space for my personal stuff as well as lmms related stuff for now.
On Tue, Apr 29, 2014 at 2:44 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote
On 04/29/2014 03:44 PM, Tres Finocchiaro wrote:
> This discussion is going off in quite a few directions. Some
> arguments are concerned with UI design. Some are concerned with UI
> responsiveness. Some are concerned with network bandwidth. Some are
> concerned with the technology behind the so
This discussion is going off in quite a few directions. Some arguments are
concerned with UI design. Some are concerned with UI responsiveness. Some
are concerned with network bandwidth. Some are concerned with the
technology behind the solution.
Jonathan brings up a valid point about the futu
On 04/29/2014 03:39 PM, Jonathan Aquilina wrote:
> Vesa I think you and others would agree I think the main focus at this
> point is a working LSP platform then we can get all fancy with
> accessing these features from within lmms at a later stage. This is a
> massive task and one that will take qu
Vesa I think you and others would agree I think the main focus at this
point is a working LSP platform then we can get all fancy with accessing
these features from within lmms at a later stage. This is a massive task
and one that will take quite a few release before we have something stable
and can
On 04/29/2014 01:20 PM, Tobias Doerffel wrote:
> 2014-04-29 8:06 GMT+02:00 Vesa :
>> Particularly, the file browser shouldn't get broken so horribly as in
>> these pictures:
> What's broken except this is an very early screenshot and the actual
> master branch was much more advanced at the end?
I
On 04/29/2014 12:23 PM, Raine M. Ekman wrote:
> Citerar Vesa :
>> If there has to be an option for downloading presets/samples/whatever
>> from LSP or elsewhere, fine... but it should be configurable, it should
>> not break existing functionality, and it needs to be implemented better.
>>
>> Partic
I wonder thinking about this again. instead of using git. to download I
wonder if we could integrate rsync into lmms for this. Rsync boasts quick
download speeds even for massive downloads. I have worked with a directory
with over 200mb worth of patches where i worked as I had put together a
bash s
I dont know how you guys feel at this point feel about this, but do you
think we should put this on hold for now due to LSP2.0 being under
development still. This feature I think is one that will be a long term
subproject here, granted all that has been mentioned so far is valid.
On Tue, Apr 29,
2014-04-29 8:06 GMT+02:00 Vesa :
> Particularly, the file browser shouldn't get broken so horribly as in
> these pictures:
What's broken except this is an very early screenshot and the actual
master branch was much more advanced at the end?
> - We have to ensure that web searches do not slow down
Citerar Vesa :
> If there has to be an option for downloading presets/samples/whatever
> from LSP or elsewhere, fine... but it should be configurable, it should
> not break existing functionality, and it needs to be implemented better.
>
> Particularly, the file browser shouldn't get broken so horr
On LSP we could provide a comment system where users can provide comments
of tweaks they did etc. and even share new versions of the same preset etc
On Tue, Apr 29, 2014 at 10:26 AM, Vesa wrote:
> On 04/29/2014 11:09 AM, oeai wrote:
> > On 29.04.2014 11:52, Vesa wrote:
> >> Sorry but I have no
Vesa exactly my point with my last email in this regard. This is getting
me to think how hard it would be to implement some versioning system on the
sharing platform.
On Tue, Apr 29, 2014 at 9:52 AM, Vesa wrote:
> On 04/29/2014 10:45 AM, oeai wrote:
> > Yes, it is all important and good questi
I might have another solution for version control which would require
another platform to work called alfresco which is a document management
system, but we can adapt it to do what we want. I will research this as
another potential solution.
On Tue, Apr 29, 2014 at 10:42 AM, oeai wrote:
> i thi
i think that every programmer here understands the difference between
ftp and git work
and also about project/presets store and modifications.
On 29.04.2014 12:26, Vesa wrote:
> Eh, that just seems like too much complexity. We'd have to code in a
> understandable and easily usable API for all of
On 04/29/2014 11:09 AM, oeai wrote:
> On 29.04.2014 11:52, Vesa wrote:
>> Sorry but I have no idea what you're trying to say here. Git is for
>> source code version control, it has nothing to do with downloading
>> presets/samples/projects online.
> with
> git clone you can download all presets/
On 29.04.2014 11:52, Vesa wrote:
> Sorry but I have no idea what you're trying to say here. Git is for
> source code version control, it has nothing to do with downloading
> presets/samples/projects online.
with
git clone you can download all presets/samples/projects ,
git submodule get some of
On 04/29/2014 10:45 AM, oeai wrote:
> Yes, it is all important and good questions to think on architecture.
> i think that maybe these cases have already been done in git.sources, so
> all you need is include git in compilation check process and this is why
> using API can be better.
Sorry but I
Yes, it is all important and good questions to think on architecture.
i think that maybe these cases have already been done in git.sources, so
all you need is include git in compilation check process and this is why
using API can be better.
if you can "git remote-testgit" (needs git_remote_helpe
On 04/29/2014 08:38 AM, Jonathan Aquilina wrote:
> FL actually does something similar in the sense it allows you to
> download stuff from within the DAW.
>
I don't care what FL does.
If there has to be an option for downloading presets/samples/whatever
from LSP or elsewhere, fine... but it should
FL actually does something similar in the sense it allows you to download
stuff from within the DAW.
On Tue, Apr 29, 2014 at 7:29 AM, Vesa wrote:
> On 04/29/2014 08:27 AM, Jonathan Aquilina wrote:
> > Vesa we arent saying social media here. we are talking about easy
> > access to presets etc fo
On 04/29/2014 08:27 AM, Jonathan Aquilina wrote:
> Vesa we arent saying social media here. we are talking about easy
> access to presets etc for download
We have that. It's called Firefox...
--
"Accelerate Dev Cycles wit
Vesa we arent saying social media here. we are talking about easy access to
presets etc for download
On Tue, Apr 29, 2014 at 5:37 AM, Vesa wrote:
> On 04/28/2014 10:47 PM, Tobias Doerffel wrote:
> >
> >
> > It was reading an index file at the sharing platform
> > (http://lmms.sourceforge.net/We
On 04/28/2014 10:47 PM, Tobias Doerffel wrote:
>
>
> It was reading an index file at the sharing platform
> (http://lmms.sourceforge.net/WebResources/Index) and downloaded
> individual resources on-demand. Technically everything is in place in
> the old-master branch and only needs to be ported to
I like the idea of versioned changes similar to a wiki or a git repo.
What I find pretty exciting is this feature in it's basic form was already
started! :)
- tres.finocchi...@gmail.com
On Mon, Apr 28, 2014 at 4:47 PM, Jonathan Aquilina
wrote:
> Git is designed for version control of code. Wh
Git is designed for version control of code. What I would say is that the
with LSP we provide a detailed description of the preset and if someone
modifies it or updates it for their own needs they upload it to LSP again.
Only the original owner can remove presets that they fix and submit to the
sha
That's nice! But it's not the same =) as just a file sharing storage
through git it's better to share unzipped files to get many versions of
1 file.
for 1 file you can have many tune-ups to get completely different sounds
and using file storage will make it very large, but using diff/patch of
le
Hi,
we had that feature before in the old master branch:
http://www-user.tu-chemnitz.de/~doto/lmms/lmms-goes-online.png
http://www-user.tu-chemnitz.de/~doto/lmms/lmms-goes-online-2.png
It was reading an index file at the sharing platform (
http://lmms.sourceforge.net/WebResources/Index) and down
yeah, it is.
to navigate through items online you'll get more folders or just switch
between branches, so you'll get a list of branches and will get a file
when you switch to it. Or just clone it all and work without latencies
(that will lower hosting pressure probably).
user creating etc. can
On Mon, Apr 28, 2014 at 11:07 AM, Jonathan Aquilina
wrote:
> Oeai are you talking about a cloud storage solution in a nut shell?
>
Where it resides would be web based and ideally in a distributed cloud
service, but that digs a bit deep into the design.
I believe he's speaking a bit more high-lev
cloud storage will not permit you to revert changes, imho it is easier
to make through a git/mercurial, this can work on top of cloud as
storage, but needs more functions for groups and accounts and files too.
to share .xml through cloud - you won't see any changes and with git
you'll get those
Oeai are you talking about a cloud storage solution in a nut shell?
On Mon, Apr 28, 2014 at 4:56 PM, oeai wrote:
> there are few tabs on the left, so add one more - online repo to browse
> different branches/instrumens/styles . So when you switch the branch you'll
> get a new set of instrument
there are few tabs on the left, so add one more - online repo to browse
different branches/instrumens/styles . So when you switch the branch
you'll get a new set of instrument presets or just songs sorted in styles.
to pick one - just like a saves it to disk /raw.github/ or get a full
list of al
I have an idea how we can implement this within lmms. We could actually
create a button within lmms that opens up like a pop up window which
connects to LSP and allows users to download presets etc.
On Mon, Apr 28, 2014 at 3:57 PM, Tres Finocchiaro <
tres.finocchi...@gmail.com> wrote:
> oe,
>
>
oe,
I like this idea conceptually. I would call it a git-style repo for
presets plus native LMMS "git clone"-style support.
I'm not sure git would be the best technology for this but you bring up a
very valid point. It's similar to how KDE allows downloading wallpapers
from kde.org without a we
The way things currently work for presets you save them to a file. Having
an api will take alot of work and man power which we dont have at this
stage.
On Mon, Apr 28, 2014 at 3:38 PM, oeai wrote:
> well, the thing was to modify presets and see it changes.
> does lsp have api to use in lmms wit
well, the thing was to modify presets and see it changes.
does lsp have api to use in lmms without browser?
On 28.04.2014 17:30, Jonathan Aquilina wrote:
> That is the whole goal of LSP. to provide a sharing platform for
> presets etc
>
--
symbiants
oe ai
--
That is the whole goal of LSP. to provide a sharing platform for presets etc
On Mon, Apr 28, 2014 at 3:27 PM, oeai wrote:
> once, i thought of collaboration platform on lmms base (was discussed once)
> so i thought that those files can be uploaded to git and that git repo
> could be a part of
once, i thought of collaboration platform on lmms base (was discussed once)
so i thought that those files can be uploaded to git and that git repo
could be a part of interface for open projects and same scheme could be
used for instrument presets, but it should be sorted for few projects or
maybe b
71 matches
Mail list logo
