On 07/14/2014 08:52 PM, Tres Finocchiaro wrote:
> Weren't you marking some as 1.0, bugs and enhancements? Have I lost
> my memory?
I've done that on occasion.
--
Want fast and easy access to all the code in your enterpri
Weren't you marking some as 1.0, bugs and enhancements? Have I lost my
memory?
- tres.finocchi...@gmail.com
On Mon, Jul 14, 2014 at 1:37 AM, Jonathan Aquilina
wrote:
> What I was spearheading was transferring of issues and enhancements from
> SF to github. If need be I can assume this role an
What I was spearheading was transferring of issues and enhancements from SF
to github. If need be I can assume this role and mark as duplicates, but I
think its better that someone who knows the code or works with the code
more then I does this.
On Mon, Jul 14, 2014 at 6:50 AM, Tres Finocchiaro <
Some people are filing a separate bug for each usability improvement they
want and there doesn't seem to be much control over them recently (marking
some as duplicates, categorizing some as enhancements, marking some as 1.1,
etc).
Jonathan, I thought you were the one that was spearheading this? W
what was that baseball movie.. now .. well not exact quote but
/"If you build it, i will test" /
:p
(win32)
--
View this message in context:
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Milestones-for-1-1-release-tp8879p8932.html
Sent from the lmms-devel mailing list archive at Nabb
> I described the necessary few steps a few times - it's really not hard
> and definitely not some kind of magic that nobody else besides me can
> do.
I tried one evening and couldn't figure it out. But that's not really the
point... Ubuntu may not be that hard either, but someone unfamilar coul
2014-05-21 3:43 GMT+02:00 Tres Finocchiaro :
> IIRC, someone (other than Toby) recently got Win32 to build (minus the NSIS
> part, but that is minor). Can't remember offhand who it was.
I described the necessary few steps a few times - it's really not hard
and definitely not some kind of magic th
Yes, I have recently succeeded in building lmms for windows. I could do a
test build if its needed.
On 21 May 2014 03:44, "Tres Finocchiaro" wrote:
>
>
> If you want to build binary packages from the branch, you're entirely
>> free and welcome to do so. Just remember to note anyone using/trying
If you want to build binary packages from the branch, you're entirely
> free and welcome to do so. Just remember to note anyone using/trying the
> binaries that it's not an official release and only exists for testing
> purposes.
>
I can (and will if needed) but the platform I've documented creati
On 05/21/2014 03:26 AM, Tres Finocchiaro wrote:
> You probably won't want to hear this, but if the team can churn out
> binary builds of the sample exact stuff you're likely to get much
> quicker feedback. Particularly the Ubuntu and Windows sides of the
> fence.
>
>
If you want to build binary p
You probably won't want to hear this, but if the team can churn out binary
builds of the sample exact stuff you're likely to get much quicker
feedback. Particularly the Ubuntu and Windows sides of the fence.
-Tres
- tres.finocchi...@gmail.com
On Tue, May 20, 2014 at 6:36 PM, Vesa wrote:
> I'
I'd like to note here, that it'd be extremely helpful if people who are
capable of compiling from source would test out the sample-exact models
branch a bit, if we can get some testing and find out any possible
problems in it, then there might be a higher chance that we could get
this feature stabl
I have now created the branch "models" on the main repository, and added
an initial commit which contains all my sample-exact model & controller
work.
https://github.com/LMMS/lmms/commits/models
Everyone is welcome to try it out, and also contribute in developing it.
This is topic has gone slightly off track, but if it helps, my tracks broke
significantly from 0.4 to 1.0. The one that made it on the LMMS Artists CD
had to be remastered and re-leveled prior to sending to Uros and I still
don't think it sounds right. I'm fine with this because to be progressiv
I'm not really sure what to do with the peak controller, though.
It seems like it's not actually a "peak" controller - looking at the
codebase, it actually takes the RMS of each period of audio, then
updates the controller from that. I have a feeling it's written this way
to overcome earlier limit
On 05/19/2014 10:26 PM, Vesa wrote:
> On 05/19/2014 10:06 PM, Vesa wrote:
>> To elaborate, I have this working already in such a way that existing,
>> non-sample-exact models (ie. all of them) still work as they always
>> have, even with controllers - it's just the new sample-exact
>> buffer-passin
>
> I can't really say anything about that... ...Well, I'm probably totally
> useless in that regard, but I hope you'll find the help you need.
>
Fair enough, but remember that I am willing to provide an environment for
someone who can help.
The three bugs preventing me from recommending 1.x.x on
On 05/19/2014 11:02 PM, Tobias Doerffel wrote:
> Hi,
>
> 2014-05-19 21:57 GMT+02:00 Vesa :
>> Ok, can you create the branch then - I have some code to put in there...
> you should be able to do that yourself by directly pushing your new
> branch to the LMMS repository :-)
>
Oh, right - I forgot I
Hi,
2014-05-19 21:57 GMT+02:00 Vesa :
> Ok, can you create the branch then - I have some code to put in there...
you should be able to do that yourself by directly pushing your new
branch to the LMMS repository :-)
Toby
---
On 05/19/2014 10:54 PM, Tobias Doerffel wrote:
> 2014-05-19 21:06 GMT+02:00 Vesa :
>> In that case, should we maybe create a separate branch for it, so it'd
>> be possible to collaborate on this?
> Yes definitely - we generally should more work on topic branches so
> they can mature independently w
2014-05-19 21:06 GMT+02:00 Vesa :
> In that case, should we maybe create a separate branch for it, so it'd
> be possible to collaborate on this?
Yes definitely - we generally should more work on topic branches so
they can mature independently without delaying pull requests until
master is open aga
On 05/19/2014 10:44 PM, Tres Finocchiaro wrote:
>
> In all seriousness, you and Jonathan are probably about the only
> ones in here who have access to Macs, you're the ones familiar
> with them, so it kind of falls on you to get these Mac-specific
> bugs fixed... It's just very hard
>
> You mean the elephant that has been merged in the master branch and
> working perfectly fine for over a month now?
>
Yes, that elephant.
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instant
On 05/19/2014 10:51 PM, Tres Finocchiaro wrote:
>
> .. oh and undo. Le'ts not forget that elephant in the room. :)
You mean the elephant that has been merged in the master branch and
working perfectly fine for over a month now?
---
>
> I'd like to assign resources to something that does.
>
.. oh and undo. Le'ts not forget that elephant in the room. :)
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Seleni
>
> In all seriousness, you and Jonathan are probably about the only ones
> in here who have access to Macs, you're the ones familiar with them, so
> it kind of falls on you to get these Mac-specific bugs fixed... It's
> just very hard for anyone who doesn't know about Macs and doesn't own one
> to
On 05/19/2014 10:06 PM, Vesa wrote:
> To elaborate, I have this working already in such a way that existing,
> non-sample-exact models (ie. all of them) still work as they always
> have, even with controllers - it's just the new sample-exact
> buffer-passing methods that are still causing problems.
On 05/19/2014 09:59 PM, Tobias Doerffel wrote:
> 2014-05-19 20:45 GMT+02:00 Vesa :
>> Ones that are still uncertain:
>> - the sample-exact models and the new buffer-passing architecture - I've
>> been working on it today locally, and I've got most of the structures in
>> place, partially rewrote th
2014-05-19 20:45 GMT+02:00 Vesa :
> Ones that are still uncertain:
> - the sample-exact models and the new buffer-passing architecture - I've
> been working on it today locally, and I've got most of the structures in
> place, partially rewrote the LFO controller while I was at it, I'm just
> runnin
On 05/19/2014 07:19 PM, Tres Finocchiaro wrote:
>
> Ok, so the plan is to refine those features already committed?
>
> The reason I ask is because I would like the team to offer official
> OSX download, but I don't feel comfortable with the stability until a
> few bugs are fixed.
Well, send me a m
014-05-19 18:18 GMT+02:00 Jonathan Aquilina :
> @toby I think a valid quesiton here would be at what point will we branch
> master for 1.1 stabilization?
We will see. Maybe in one or two weeks. In the end it doesn't make any
difference, we have to stabilize the code base in either case. At the
sim
>
> We already have a sort of unofficial feature freeze. Large new features
> won't be merged anymore until we branch out 1.1 to its own branch.
> Smaller new features that aren't likely to cause instability - such as
> your vst/sf2 commit - can still get in...
Ok, so the plan is to refine those
@toby I think a valid quesiton here would be at what point will we branch
master for 1.1 stabilization?
On Mon, May 19, 2014 at 6:16 PM, Vesa wrote:
> On 05/19/2014 07:14 PM, Jonathan Aquilina wrote:
> > Shouldnt we branch the changes after merging 1.0 bug fixes to master
> > that way we dont e
On 05/19/2014 07:14 PM, Jonathan Aquilina wrote:
> Shouldnt we branch the changes after merging 1.0 bug fixes to master
> that way we dont end up with a bottle neck of new features waiting to
> be merged that would probably need to be rebased due to master
> diverging too much?
>
We're periodicall
Shouldnt we branch the changes after merging 1.0 bug fixes to master that
way we dont end up with a bottle neck of new features waiting to be merged
that would probably need to be rebased due to master diverging too much?
On Mon, May 19, 2014 at 6:09 PM, Vesa wrote:
> On 05/19/2014 06:09 PM, Tr
On 05/19/2014 06:09 PM, Tres Finocchiaro wrote:
> I've observed quite a few changes to master for our 1.1 release.
>
> Should the project consider focusing stability on a few major
> milestone features?
We already have a sort of unofficial feature freeze. Large new features
won't be merged anymore
I've observed quite a few changes to master for our 1.1 release.
Should the project consider focusing stability on a few major milestone
features?
I have a list of items in my head but before rattling them off, I'd like to
understand a bit better how the "funneling effect" will happen as we get
c
37 matches
Mail list logo
