From: Vesa <di...@nb...> - 2014-07-29 09:23:50
|
So, I'm just going to put this out here. The future of LMMS is very uncertain right now. Sure we have lots of activity on the mailing list, people working enthusiastically on what they can, and that's all great! But there are some looming issues that are getting worse as we go on. The problem is, we're getting to the point where the limitations of the current LMMS core engine are starting to severely handicap what we can do with the software. Sure, we can improve functionality - sample tracks, automation, etc. - but many things are hard or impossible to do because of the limitations: Jack support, RT-safety, being able to integrate with external software, reliable live usage... Paul Giblock had the idea of migrating LMMS to use his Unison core. This would be a good idea, if we had the resources to make that happen, but currently... let's look at the situation: I currently write about 50% of the code for LMMS, and the rest are small improvements - mostly UI, build system, localization or small optimizations... and I'm not skilled enough to do RT- or systems coding, or to design a new engine for LMMS. The ones who do have the skills (Toby, Paul) are too busy with RL and don't have enough time to do this kind of work, and AFAIK none of our other developers have the required skillsets to migrate LMMS to a new core (please correct me if I'm wrong!). So let's brainstorm some ideas how we can get over this hurdle. If we could get a modern, RT-safe engine for LMMS, there's such a huge potential that could be done with it - we could really make LMMS into a professional-grade DAW that is still easy enough to get into for beginners. I'll throw some ideas out here: 1. Kickstarter campaign for a hired developer? Do a kickstarter to raise some funds, then use the money to hire a developer to help with the migration to a new core. Do we have enough of a userbase that this could be feasible? 2. Try to find a developer who'd be willing to work on this project. This has (and is) been tried, with no luck so far. 3. Try to improve the current engine gradually. I've been attempting this, but again, see re: lack of skill in RT-coding. Paul has also earlier opined that the current engine is unsalvageable, not sure about that but it definitely is challenging. 4. Google Summer of Code? This might be an option for next year, we might want to start looking into this if it's something we want to do. Ok that's all I got for now. Anyone else have any ideas? Please feel free to pipe in, there are no bad ideas at this point. If we can figure out a game plan, we could then skip the 1.3 release in order to concentrate on the codebase rehaul, and present a brand new and improved LMMS 2.0 next year. That'd be awesome if we could somehow make that happen... |
From: oeai <oe...@sy...> - 2014-07-29 09:59:34
|
the very first idea i had was to invite someone from other OS project psycle, qtracktor, ardour, zyna -> maybe not the software suite, but software synth maybe jack-dev itself the kisckstarter idea i had was not in to going for developers, but to propose something new for people/company the company idea is more like startup and for both cases there are some obligations, because of money rise as for idea i am using enlightenment as Desktop Environment and i'd like to make sounds for e, but not the midi or ogg/mp3, with lmms engine i can create any instrument and after integration with DE it would be nice to export song or sounds set as the desktop theme -> going forward they are supported by samsung, this means that this DE can be used for android -> mobile device sound engine - that's what i was thinking for kickstarter of lmms-project. On 29.07.2014 13:23, Vesa wrote: > So, I'm just going to put this out here. The future of LMMS is very > uncertain right now. Sure we have lots of activity on the mailing list, > people working enthusiastically on what they can, and that's all great! > But there are some looming issues that are getting worse as we go on. > > The problem is, we're getting to the point where the limitations of the > current LMMS core engine are starting to severely handicap what we can > do with the software. > > Sure, we can improve functionality - sample tracks, automation, etc. - > but many things are hard or impossible to do because of the limitations: > Jack support, RT-safety, being able to integrate with external software, > reliable live usage... > > Paul Giblock had the idea of migrating LMMS to use his Unison core. This > would be a good idea, if we had the resources to make that happen, but > currently... let's look at the situation: I currently write about 50% of > the code for LMMS, and the rest are small improvements - mostly UI, > build system, localization or small optimizations... and I'm not skilled > enough to do RT- or systems coding, or to design a new engine for LMMS. > The ones who do have the skills (Toby, Paul) are too busy with RL and > don't have enough time to do this kind of work, and AFAIK none of our > other developers have the required skillsets to migrate LMMS to a new > core (please correct me if I'm wrong!). > > So let's brainstorm some ideas how we can get over this hurdle. If we > could get a modern, RT-safe engine for LMMS, there's such a huge > potential that could be done with it - we could really make LMMS into a > professional-grade DAW that is still easy enough to get into for beginners. > > I'll throw some ideas out here: > > 1. Kickstarter campaign for a hired developer? Do a kickstarter to raise > some funds, then use the money to hire a developer to help with the > migration to a new core. Do we have enough of a userbase that this could > be feasible? > > 2. Try to find a developer who'd be willing to work on this project. > This has (and is) been tried, with no luck so far. > > 3. Try to improve the current engine gradually. I've been attempting > this, but again, see re: lack of skill in RT-coding. Paul has also > earlier opined that the current engine is unsalvageable, not sure about > that but it definitely is challenging. > > 4. Google Summer of Code? This might be an option for next year, we > might want to start looking into this if it's something we want to do. > > Ok that's all I got for now. Anyone else have any ideas? Please feel > free to pipe in, there are no bad ideas at this point. > > If we can figure out a game plan, we could then skip the 1.3 release in > order to concentrate on the codebase rehaul, and present a brand new and > improved LMMS 2.0 next year. That'd be awesome if we could somehow make > that happen... > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > -- RA -- Symbiants oe ai |
From: Vesa <di...@nb...> - 2014-07-29 10:03:20
|
On 07/29/2014 12:58 PM, atumra wrote: > the very first idea i had was to invite someone from other OS project > psycle, qtracktor, ardour, zyna -> maybe not the software suite, but > software synth > maybe jack-dev itself Has been tried, but those people are mostly busy with their own respective projects. Probably the most they can offer is advice and information, not actual coding (especially not a large scale coding project like this). |
From: oeai <oe...@sy...> - 2014-07-29 10:20:55
|
well, it's usual case. the next step of engine can be a new music-codec - so maybe ask some mpg123 or FLAC imagine that oscillators are different language types, to encode few waves (phrases) you just need to set few words for it for hard cases you'll need clear bit types (soundtrack), but they also can be splitted for parts yes it is something complicated, but as a music device with low-end encoding this can be a new "sound-machine" device kickstarter campaign if you ready for it (a better way of ipod with own codec) it is similar to vector images encoders, that's probably something new. not sure on energy consumption, but the fun thing will be to add some new sounds and effects to music aka DJ-FX and DJing software is a very large audience, many companies producing different hard and soft that is in demand. On 29.07.2014 14:03, Vesa wrote: > On 07/29/2014 12:58 PM, atumra wrote: >> the very first idea i had was to invite someone from other OS project >> psycle, qtracktor, ardour, zyna -> maybe not the software suite, but >> software synth >> maybe jack-dev itself > Has been tried, but those people are mostly busy with their own > respective projects. Probably the most they can offer is advice and > information, not actual coding (especially not a large scale coding > project like this). > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > -- RA -- Symbiants oe ai |
From: Vesa <di...@nb...> - 2014-07-29 10:29:43
|
On 07/29/2014 01:20 PM, oeai wrote: > well, it's usual case. > the next step of engine can be a new music-codec - so maybe ask some > mpg123 or FLAC > imagine that oscillators are different language types, > to encode few waves (phrases) you just need to set few words for it > for hard cases you'll need clear bit types (soundtrack), but they also > can be splitted for parts > yes it is something complicated, but as a music device with low-end encoding > this can be a new "sound-machine" device kickstarter campaign if you > ready for it (a better way of ipod with own codec) > it is similar to vector images encoders, that's probably something new. > not sure on energy consumption, but the fun thing will be to add some > new sounds and effects to music aka DJ-FX > and DJing software is a very large audience, many companies producing > different hard and soft that is in demand. I'm not really sure what you're even suggesting here, but I think you're probably misunderstanding the issue. We're not looking to fund a music device or a new codec or any such thing. This is about LMMS, and how we can /continue developing LMMS as a software/, nothing more. The problem is that the /core part of the LMMS software itself/ is broken and we need to fix that so that LMMS can have a future and not die, and for this we need developers who are capable of writing such code. What I'm looking for here is ideas for how we can make that happen. |
From: oeai <oe...@sy...> - 2014-07-29 11:45:33
|
Well it is all about it, i thought To get into a kickstarter campaign you need to propose something for end-users - the device is that thing. to get more developers you can propose lmms-engine or codec for other markets not only for musicians, these markets i've described. For example Firefox has integrated Unreal Engine API into their platform, this means that there is more interest for games and game-dev probably needs also soft-synth for music backgrounds and just sounds, they all got a lot of developers who probably can help to integrate sound engine and sharpen it, just to get rid of flash (in case of codec) or to create more complex themes and lower disk capacity (as a game sound engine). On 29.07.2014 14:29, Vesa wrote: > On 07/29/2014 01:20 PM, oeai wrote: >> well, it's usual case. >> the next step of engine can be a new music-codec - so maybe ask some >> mpg123 or FLAC >> imagine that oscillators are different language types, >> to encode few waves (phrases) you just need to set few words for it >> for hard cases you'll need clear bit types (soundtrack), but they also >> can be splitted for parts >> yes it is something complicated, but as a music device with low-end encoding >> this can be a new "sound-machine" device kickstarter campaign if you >> ready for it (a better way of ipod with own codec) >> it is similar to vector images encoders, that's probably something new. >> not sure on energy consumption, but the fun thing will be to add some >> new sounds and effects to music aka DJ-FX >> and DJing software is a very large audience, many companies producing >> different hard and soft that is in demand. > > I'm not really sure what you're even suggesting here, but I think > you're probably misunderstanding the issue. We're not looking to fund > a music device or a new codec or any such thing. This is about LMMS, > and how we can /continue developing LMMS as a software/, nothing more. > > The problem is that the /core part of the LMMS software itself/ is > broken and we need to fix that so that LMMS can have a future and not > die, and for this we need developers who are capable of writing such code. > > What I'm looking for here is ideas for how we can make that happen. > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel -- Symbiants oe ai |
From: Vesa <di...@nb...> - 2014-07-29 10:31:14
|
What I'm saying is, your ideas for music devices and such are very interesting and all, but I don't really see how they would help us fix the LMMS software. |
From: drunken j. <mrd...@ai...> - 2014-07-29 12:21:20
|
I'm not very knowledgeable on coding at all & I'm not familiar with the Unison Core you mentioned but I know there have been numerous programmers who have released their source code for tracker sequencers. I know trackers operate in a very different fashion than LMMS but it seems to me in theory you could take the audio engine from one of those and code a sequencer to be like LMMS. Rebuilding from the ground up seems like a pretty daunting task even if a successful kickstarter campaign brought in a talented programmer, nearly all the fully functional DAW's have been in development anywhere between 5-15 years or more Also another idea the guy who made SFXR also developed a sequencer of sorts awhile ago -- View this message in context: http://linux-multimedia-studio-lmms.996328.n3.nabble.com/LMMS-the-future-ideas-tp9795p9803.html Sent from the lmms-devel mailing list archive at Nabble.com. |
From: musikbear <mk...@ho...> - 2014-07-29 13:07:37
|
Perhaps a 2.0 on an other core is not a 2 y prospect, but a 5+ ..? imo we should improve and expand /what we got/. But all work on current core, should have a pin stuck in it. A pin marked /'re-usable' as module/. Vesa, you are the one who can say if such /modulation/ at all is possible? If it is, then a 2.0lmms would not be a 'scratch' project, and further devellopment on 1.x, would also be a little'working for the future' Does that sounds like garbadge? -- View this message in context: http://linux-multimedia-studio-lmms.996328.n3.nabble.com/LMMS-the-future-ideas-tp9795p9804.html Sent from the lmms-devel mailing list archive at Nabble.com. |
From: Tres F. <tre...@gm...> - 2014-07-29 13:51:38
|
This is an interesting topic to me. I tried visualizing the idea of a kickstarter as well. Here's an email I sent Toby in 2012: Tobydox, > Would you be interested in a Kickstarter project for your work on > LMMS? The idea is to get some of the user's input on what they consider > important bugs, and to compensate you monetarily (and/or other developers) > for the hard work. > Let me know. I already have some interest from some small donors. I know > people are willing to spend big bucks on commercial software, proposing > that a fraction of that toward this excellent product I think would be > well received by the LMMS community. I look forward to hearing back. I have > some ideas of my own, but I want to see if you are interested in the idea > first. He did reply with some useful information, but for the most part it was a no-go due to the mentoring time required to get a new developer involved. Two years later we are probably in a better situation as it appears we have more people active with the codebase making the mentoring process more possible. Here was my wish list in 2012: > Toby, > My biggest win: > > - Allow copy/paste/drag multiple tracks through the song editor (which > I understand is not a small task). > > Also would like to: > > - Hire a graphic designer for branding (if that's ok) > > > - Provide enough money to remove the Babylon toolbar prompt from the > Windows installer (Edit 2014: This has since been removed) > > My friends would like: > > - Better handling of VST crashes > > > - Better handling of when sound stops working (more complains on > windows than Linux) > > And on my wish list is: > > - Easier bug tracking (such as through "report a problem" style menu) > (Edit 2014: GitHub has helped this a lot) > > > - Mac support (perhaps we would have enough money to fund the purchase > of a Mac + developer tools). (Edit 2014: Bought the hardware myself, almost > there) > > > - Portability: Loading third party sound fonts/samples from relative > paths to home directory between Linux and Windows. (i.e. > /home/tfino/lmms/samples/piano.sf2 maps to > C:\Users\tfino\lmms\samples\piano.sf2) (Edit 2014: This has been fixed as > well) > > My motivation comes from a new project where we are working very hard with > pure LMMS. One collaborator is on Linux, two are on Windows and two are on > Macintosh. > I also recently finished doing a technical review for a *LMMS book for > Packt Publishing*, which has given me a lot of motivation and > understanding with the LMMS software! > I understand nearly none of this addresses a brand new core but this was before I got actively involved on the developer team. If I were to recreate this list now, it would be a bit different. I'd like to make a race car reference here a bit... Although musicBear and oeai may not be talking about redesigning the motor, the body and paint is what everyone sees, so their concerns are likely to help get buy-in regardless of the difficulty or significance. >From a "how to get developers" perspective... I struggle to get developers for my personal projects (and I pay very well) so this is a tough task. Most people won't leave their day job for a contract so they're working two jobs and one is likely to suffer. Furthermore, you'll need a project manager to spearhead the campaign too. I don't know if the people we have currently could manage a project of that size. I'm very interested to see how this topic develops. :) -Tres |
From: Vesa <di...@nb...> - 2014-07-29 13:58:29
|
On 07/29/2014 04:51 PM, Tres Finocchiaro wrote: > He did reply with some useful information, but for the most part it > was a no-go due to the mentoring time required to get a new developer > involved. > > Two years later we are probably in a better situation as it appears > we have more people active with the codebase making the mentoring > process more possible. I think if we can get a paid developer, part of the project would be orientation, where all of us could pitch in to help the developer get acquintated with the codebase. This isn't the biggest hurdle here IMO. > > Here was my wish list in 2012: > > I understand nearly none of this addresses a brand new core but this > was before I got actively involved on the developer team. If I were > to recreate this list now, it would be a bit different. Yes. Most of the things on your wishlist are things that we can probably implement just fine on our own. The core engine is the problematic part. IMO if we do get a paid developer, we should focus their efforts on the hard parts, otherwise it would just be wasteful. |
From: Tres F. <tre...@gm...> - 2014-07-29 14:55:23
|
> > This isn't the biggest hurdle here IMO. The core engine is the > problematic part. I'm going to dive a bit more into the kickstarter idea... When you ask the public to fund something large, you have to make promises that meet public demand. Despite what your opinion is about the importance of developing the "core" (infrastructure, etc), I can assure you more people will be excited when undo is working (and I mean properly, not what we have now) and more people will be interested when they can export MP3s than they will be about a smoother running core. We also need to target our userbase. If our users want to make Skrillex "growls", we make that possible. The "growls" and "wobbles" get buy in from people who stole Ableton and FL Studio and are sick of breaking the law. Our campaign video represents an aggregation of the requests that are both popular, possible and make sense in our budget and timeline. I know you are trying to be realistic, but when you close with "there are no bad ideas at this point" you have no right to minimize and dismiss what we feel is important. (with love) -Tres |
From: Tres F. <tre...@gm...> - 2014-07-29 15:00:08
|
^-- I realize after re-reading this may minimize the importance of a core rewrite. This wasn't my intention... I don't want to shove that "elephant in the living room" aside here. :) |
From: Vesa <di...@nb...> - 2014-07-29 15:16:22
|
On 07/29/2014 05:55 PM, Tres Finocchiaro wrote: > > This isn't the biggest hurdle here IMO. The core engine is the > problematic part. > > > I'm going to dive a bit more into the kickstarter idea... > > When you ask the public to fund something large, you have to make > promises that meet public demand. > > Despite what your opinion is about the importance of developing the > "core" (infrastructure, etc), I can assure you more people will be > excited when undo is working (and I mean properly, not what we have > now) and more people will be interested when they can export MP3s than > they will be about a smoother running core. I think you misunderstand my intent a bit. It's not so much about "what is important" - it's about what we can do ourselves, what we can't do ourselves, and - if we do manage to fund and hire a developer - what that paid developer's work hours are best spent towards. UI features, functionality, etc. are of course important - but those are not things that we'd need to hire a developer for. If we pay for a developer, if we pay for X hours/days of development time, then the best way to utilize that paid time is to spend it towards things which we're not capable of implementing ourselves. > We also need to target our userbase. If our users want to make > Skrillex "growls", we make that possible. The "growls" and "wobbles" > get buy in from people who stole Ableton and FL Studio and are sick of > breaking the law. Our campaign video represents an aggregation of the > requests that are both popular, possible and make sense in our budget > and timeline. It's already plenty possible to make "Skrillex growls". I don't think that's anything we need to specifically support or encourage. Plus... people who pirate FL studio and just want to make "growls" aren't very likely to be loyal supporters of LMMS and I kind of doubt that chasing fads and pandering to the "skrillex crowd" would bring in that much support. In other words, I kind of doubt if those who are comfortable using pirated FL studio are likely to contribute money to improve an open source DAW... The improved core would however be necessary in making LMMS into a true professional quality DAW. The limitations of the current engine will catch up with us eventually, and at some point we will very likely hit a wall where we can no longer keep patching up the holes... with the improved core, we could offer reliable live performance, which would bring a whole new market to the reach of LMMS. And even if you don't perform live, being able to play your songs real time is pretty important aspect of the workflow. Even now, I'm constantly facing problems with most of my projects where my projects grow big enough that I can no longer play them back properly in LMMS, I have to export to be able to listen through. That's not very good workflow and it will only get worse the more functionality we pile up on LMMS. So it's not just about infrastructure... it's that the core rendering engine, the very heart of LMMS, is dysfunctional and needs fixing. And it's not just a "nice to have" thing... When I said the stakes were to "keep LMMS alive", I was only half joking. I very much fear that unless we manage to somehow solve this issue, LMMS faces eventual extinction as the codebase becomes unmanageable and eventually bitrots when no one is left who understands how all of it works... |
From: Tres F. <tre...@gm...> - 2014-07-29 15:40:25
|
> > I think you misunderstand my intent a bit. No one misunderstood you, Vesa. This isn't "your intent" but rather it is "our intent". This topic is the future of lmms, not the future of one particular person. Your opening statement says : The future of LMMS is very uncertain right now.... ...there are some > looming issues that are getting worse as we go on. You are trying to sell us on the idea of a tooth extraction when we don't even have a comfort level that we'll be smiling at the end of the surgery. :) > I kind of doubt if those who are comfortable using pirated FL studio are > likely to contribute money to improve an open source DAW... This assumption is wrong and your perception of our userbase is inaccurate. Do you think those who download Gimp never pirated Photoshop? Do you think those that use Kdenlive never used Premiere? Do you think Linux users are born in the womb with a Tux tattoo? Well, perhaps some of them are but the vast majority of them were raised in the world they live in. The good commercial versions do the job right the first time but come at a price that almost no one can justify so users are stuck with trying to unlock demos and stealing product keys so they can continue being productive. Every professional musician I know at one point used pirated DAW and or plugins. I gave up on LMMS and switched to Ableton a year ago because our group refused to use software without Undo. Don't minimize these things. They is important and you can't say they are not. They mean something to people and those people's opinions matter despite what path they took to get here. |
From: Tres F. <tre...@gm...> - 2014-07-29 15:54:01
|
> > On 07/29/2014 06:25 PM, drunken jesus wrote: > IMO given the limited resources the best course of action would be to try get > the current iteration of LMMS as bug free and functional as possible & promote > it a bit to gain more visibility which could lead to more skilled coders > getting involved I don't know what the best course is, but I've been very happy with the new wave of contributors, visibility and promotions. This direction you are describing is what I consider the new age renaissance period of LMMS and it's sort of the catalyst for stuff like kickstarter campaigns. Usually it requires a lead person (like Julie Uhrman/Ouya, Aaron Dunn/Musopen) stepping into a full time role to manage the tasks and/or organization. -Tres |
From: Vesa <di...@nb...> - 2014-07-29 15:57:24
|
On 07/29/2014 06:40 PM, Tres Finocchiaro wrote: > > I think you misunderstand my intent a bit. > > No one misunderstood you, Vesa. This isn't "your intent" but rather > it is "our intent". This topic is the future of lmms, not the future > of one particular person. I think you're still misunderstanding. Or if you're not, then I don't know why you keep making statements like this: > Don't minimize these things. They is important and you can't say they > are not. They mean something to people and those people's opinions > matter despite what path they took to get here. Read what I wrote in my previous post again. This isn't so much about importance, but things that we are capable of doing ourselves, and things that we need help to implement. There's no point in a crowdfunding campaign to hire a developer to write things that we can write ourselves. There is a point in hiring a developer to implement (or help implement) something which we can't do without help. > Your opening statement says : > > The future of LMMS is very uncertain right now.... ...there > are some looming issues that are getting worse as we go on. > > > You are trying to sell us on the idea of a tooth extraction when we > don't even have a comfort level that we'll be smiling at the end of > the surgery. :) I'm not trying to sell anything. I'm stating what the situation is, and asking if anyone has ideas on how we're going to solve it. Not trying to brag or anything, but at this point, I probably know the LMMS codebase better than anyone, apart from Toby (and some of the newer parts I probably know better) so I can say with confidence that unless we fix the foundations now, there absolutely **WILL** be problems later on. > This assumption is wrong and your perception of our userbase is > inaccurate. Do you think those who download Gimp never pirated Photoshop? Some of them did, some of them didn't. I'm willing to bet however that those who are comfortable with using pirated Photoshop are not the ones who donate the most money to the GIMP project. |
From: Tres F. <tre...@gm...> - 2014-07-29 19:47:01
|
> > This isn't so much about importance, but things that we are capable of > doing ourselves, and things that we need help to implement. There's no > point in a crowdfunding campaign to hire a developer to write things that > we can write ourselves. There is a point in hiring a developer to implement > (or help implement) something which we can't do without help.. > This is not necessarily true. Simply because we're capable of it doesn't mean we shouldn't seek help. You mention "professional grade DAW" but our resources are falling short on the small things to. Programmers, managers, businesses do this all the time. I'll repeat myself, you can't invite our comments and then tell us they aren't relevant. You do not get my buy in with this dismissive directive. |
From: Vesa <di...@nb...> - 2014-07-29 20:01:42
|
On 07/29/2014 10:46 PM, Tres Finocchiaro wrote: > > This isn't so much about importance, but things that we are > capable of doing ourselves, and things that we need help to > implement. There's no point in a crowdfunding campaign to hire a > developer to write things that we can write ourselves. There is a > point in hiring a developer to implement (or help implement) > something which we can't do without help.. > > > This is not necessarily true. Simply because we're capable of it > doesn't mean we shouldn't seek help. You mention "professional grade > DAW" but our resources are falling short on the small things to. > Programmers, managers, businesses do this all the time. > > I'll repeat myself, you can't invite our comments and then tell us > they aren't relevant. You do not get my buy in with this dismissive > directive. > Tres, I have no idea why you have adopted such an antagonistic attitude in this issue. Maybe we can both take a step back and calm down a bit? I'm not trying to dismiss your opinion or anything. Sure, we can seek help, and we're already doing that. Everyone is welcome to join in LMMS development and contribute in whatever way they can. You mention limited resources, which is very true - we're severely lacking in developers. If we do manage to hire a paid developer to work on LMMS for a limited time, that is also another limited resource. So it comes down to plain old logic and resource management: we have both our own limited resources, plus the limited resources we've "bought", and each of those resources should be utilized in such a way that we're utilizing the overall resources most efficiently. Ergo: it's best to use our own resources (ie. our current volunteer developers) for things which they are capable of doing, and save the "bought" resources (ie. paid developer) for things that we're not capable of implementing on our own. Because otherwise, we're just using all resources on things we could be doing on our own, and the things we can't do on our own are left undone - and when that includes fundamental things like the core, that will mean that we'll run into problems later on... which ultimately will mean that even the improvements we did get done will go to waste. Does this make sense to you? |
From: Tres F. <tre...@gm...> - 2014-07-29 20:16:37
|
> > Does this make sense to you? > I have a fundamental problem with introducing resource restrictions and limitations already on a hypothetical wish list. |
From: Vesa <di...@nb...> - 2014-07-29 20:25:19
|
On 07/29/2014 11:16 PM, Tres Finocchiaro wrote: > > Does this make sense to you? > > > I have a fundamental problem with introducing resource restrictions > and limitations already on a hypothetical wish list. Well, we can talk about hypotheticals and such, plan what we'd do if we won the lottery... or we can try to figure out a way to keep LMMS alive. The whole Kickstarter thing is just one possibility. There are other options and we don't need to get hung up on the Kickstarter. Regardless, we do need some kind of plan on how to fix the problems in our code, how to proceed forward and fix the fundamental issues... We could try fixing the current engine. The problem is, that we'd need at least one person who knows about RT coding, and we'd need that person to take a look at our current engine and at the very least tell us what we need to change and how - if that is even feasible, which I'm not sure about. We could try migrating LMMS to use the Unison core ourselves. IIRC Paul mentioned that the core parts of the Unison engine are pretty much finished, it'd just be a matter of bringing the code up to date and integrating it with LMMS. Again, we'd need some help to do that. |
From: Tres F. <tre...@gm...> - 2014-07-29 20:39:51
|
> > Well, we can talk about hypotheticals and such, plan what we'd do if we > won the lottery... or we can try to figure out a way to keep LMMS alive. > But kickstarter is the lottery, right? Ouya's goal was 1mil and they reached 9mil. How much would we we need? What do we do if it surpasses our goals? To introduce a kickstarter campaign requires quite a lot of time investment just to decide it's worth it not to mention the promo vids, PR, swag, etc. Perhaps I got focused too much on the word "kickstarter" and not enough on the term "developer" (singular not plural). If our initiatives only churn up only one person then you would likely be the best to get them acquainted and prioritized due to your involvement with the codebase, but I really hope there's room for trivial user improvements too. Sometimes the devil is in the details. |
From: Vesa <di...@nb...> - 2014-07-29 12:07:05
|
On 07/29/2014 02:45 PM, oeai wrote: > Well it is all about it, i thought > > To get into a kickstarter campaign you need to propose something for > end-users - the device is that thing. No, we don't need to. What would be promised to users would be the improvement of the LMMS software itself. The idea of a device is not really realistic in itself: firstly, do we have anyone here with any experience in designing hardware, marketing, manufacturing, etc. all that that entails? If not, it would be doomed to failure. Secondly, even if we started a campaign to create a device, then the money raised in the campaign would go towards designing and making that device, and it still wouldn't solve the problems of LMMS, the software. > to get more developers you can propose lmms-engine or codec for other > markets not only for musicians, these markets i've described. > For example Firefox has integrated Unreal Engine API into their > platform, this means that there is more interest for games > and game-dev probably needs also soft-synth for music backgrounds and > just sounds, they all got a lot of developers who probably can help to > integrate sound engine and sharpen it, just to get rid of flash (in case > of codec) or to create more complex themes and lower disk capacity (as a > game sound engine). Ok, this is again all very interesting but I'm sorry to say none of this is even remotely realistic. Codecs don't work that way... Do you know what it takes to design a codec and get it into such a state that it's in common use? That involves a lot of work, lots of developers and manhours, sponsorship from corporations/organizations who make the decisions about which codecs get supported (who also have their own interests in mind), then standardization through some large standards body, dealing with swpats, getting browsers/operating systems to support it, and all this requires that the codec offers something new that people (and businesses) will want to use it... Also, a pro-audio engine is not something you can just create as a generic project that can be reused as a game engine or some such. Games don't need pro-quality sound engines, they have their own toolkits (SDL et al.) that provide entirely sufficient facilities for sound and DSP for their needs. In this context when we say "engine" we're not talking about something comparable to flash or SDL. We're not talking about an external library here - we're talking about the core part of the LMMS software itself. It needs to be designed for LMMS, it needs to be a tight part of the LMMS codebase, it can't work as a glue-on attachment, it can't be something that is designed to be ported from application to application (like SDL or some game engines). In short, we need to be able to rewrite the central part of the LMMS software itself. It's great that you're thinking creatively, but unfortunately your ideas aren't very realistic. |
From: Vesa <di...@nb...> - 2014-07-29 13:36:02
|
On 07/29/2014 03:21 PM, drunken jesus wrote: > I'm not very knowledgeable on coding at all & I'm not familiar with the > Unison Core you mentioned but I know there have been numerous programmers > who have released their source code for tracker sequencers. I know trackers > operate in a very different fashion than LMMS but it seems to me in theory > you could take the audio engine from one of those and code a sequencer to be > like LMMS. Again, nice idea, but just not realistic. Most of the trackers (other than Renoise, and maybe Psycle) are very old. Something like Impulse Tracker was a masterpiece of coding in its time, but back then, 16-bit samples were state-of-the-art, realtime synthesis was just a dream, and CPUs were single core... there's practically nothing in that that could be translated into a modern audio engine. Also, if we consider any already existing audio engine, the code must be such that it is possible to integrate it into the LMMS codebase. This also means it must be written in C++ and has to be "compatible" (ie. not conflict) with Qt and other technologies that LMMS uses. |
From: Vesa <di...@nb...> - 2014-07-29 13:44:21
|
On 07/29/2014 04:07 PM, musikbear wrote: > Perhaps a 2.0 on an other core is not a 2 y prospect, but a 5+ ..? > imo we should improve and expand /what we got/. No offense musikbear, but what you're saying is analoguous to: "oh, I know our house is slanted and the foundations are crumbling, but maybe we can still keep building the second floor"... What we got will only take us so far, eventually we WILL hit a wall where it's no longer possible to get by with "what we got". We can probably make do and keep patching things up the best we can, but for the long run, we're going to need to fix the foundations. Here, I'm looking for ideas for how we can achieve that. > But all work on current > core, should have a pin stuck in it. A pin marked /'re-usable' as module/. > Vesa, you are the one who can say if such /modulation/ at all is possible? > If it is, then a 2.0lmms would not be a 'scratch' project, and further > devellopment on 1.x, would also be a little'working for the future' > Does that sounds like garbadge? I'm not really sure what you're suggesting here... we can try to develop and improve the current engine, but I'm not sure if it's possible to improve it sufficiently. Some argue, it isn't. I don't know, it could turn out that fixing the current engine would be even more work than just replacing it with a better one. |