Re: [LivelyKernel] 7funthings partsbin browser problem (#36)
Locked
Re: [LivelyKernel] 7funthings partsbin browser problem (#36)
 
|
Hi, Thomas
thanks for reporting. I fixed it. Reporting bugs here is fine, but if you want to create a trac ticket or write to the wiki use this register page: Best, Jens Am 10.03.2012 um 09:59 schrieb Thomas Miedema:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Hi all -
For anyone interested, I finally got a chance to finish most of what I wanted to do. FM synthesis now works - there's a brass-like and clarinet-like patch to try. Also I added a line of interpolation to banish the noise in PluckedSounds - they're really nice now. I also refactored everything so that Envelopes are free of streaming state and thus can be shared among notes. Should work in Chrome and Firefox browsers, and even in Safari with the Flash lashup.
Enjoy - Dan _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
wow, this is very clear sound now, nice :-)
Am 11.03.2012 um 03:52 schrieb Dan Ingalls:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Very nice indeed! The PluckedSound, at least, sounds better than its Squeak predecessor now. I guess we should port back your improvements :) I tried commenting out the Squeak primitive code, and found that with current CPU speeds, it is not needed anymore. On my machine the synthesis, even if interpreted, uses only about 1 % of CPU time per voice. One feature missing from the Lively keyboard (that the Squeak one had) is sustaining a note as long as a key is pressed. And loading MIDI files can't be that far off, right? Only attaching an actual keyboard might proof impractical ... On 11.03.2012, at 10:53, Jens Lincke wrote:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Dan Ingalls-4
Thanks - I'm new to the list. The sound on the keyboard is good. How
do I run the program changes to create your various other sounds. Probably a simple question, Randy Latimer On Sat, Mar 10, 2012 at 9:52 PM, Daniel Ingalls <[hidden email]> wrote: > Hi all - > > For anyone interested, I finally got a chance to finish most of what I > wanted to do. FM synthesis now works - there's a brass-like and > clarinet-like patch to try. Also I added a line of interpolation to banish > the noise in PluckedSounds - they're really nice now. I also refactored > everything so that Envelopes are free of streaming state and thus can be > shared among notes. > > Should work in Chrome and Firefox browsers, and even in Safari with the > Flash lashup. > > http://lively-kernel.org/repository/webwerkstatt/users/Dan/SoundTest2.xhtml > > Enjoy > > - Dan > > _______________________________________________ > lively-kernel mailing list > [hidden email] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Bert Freudenberg
Hi Bert - Yes please do the back-port! The only changes you need are the one-line interpolation in the mix... method to banish noise and the refs to this.damp to make the high notes ring better. The changes for shareable envelopes are vast - I wouldn't bother. Keyboard sustain will be my next move (easy) but I'm not sure it would be that hard to read a real keyboard. Let's find out how to read USB input - nice for all sorts of fun hardware experiments (have you got your strawberry pie yet? ;-) - Dan -------------- Sent from my iPhone
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by R.D. Latimer
If I understand correctly, select the expression and use cmd-D (do it) to evaluate it.
- D --------- Sent from my iPhone On Mar 12, 2012, at 6:37 AM, "R.D. Latimer" <[hidden email]> wrote: > Thanks - I'm new to the list. The sound on the keyboard is good. How > do I run the program changes to create your various other sounds. > Probably a simple question, > Randy Latimer > > On Sat, Mar 10, 2012 at 9:52 PM, Daniel Ingalls <[hidden email]> wrote: >> Hi all - >> >> For anyone interested, I finally got a chance to finish most of what I >> wanted to do. FM synthesis now works - there's a brass-like and >> clarinet-like patch to try. Also I added a line of interpolation to banish >> the noise in PluckedSounds - they're really nice now. I also refactored >> everything so that Envelopes are free of streaming state and thus can be >> shared among notes. >> >> Should work in Chrome and Firefox browsers, and even in Safari with the >> Flash lashup. >> >> http://lively-kernel.org/repository/webwerkstatt/users/Dan/SoundTest2.xhtml >> >> Enjoy >> >> - Dan >> >> _______________________________________________ >> lively-kernel mailing list >> [hidden email] >> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel >> lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Bert Freudenberg
I've always thought that "plucked string" had an ungraceful decay (should be longer -- we finessed this by adding a little reverb). Cheers, Alan
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Folks -
Over the weekend i did some Samurai coding. I haven't been able to do much of this recently, but it is very instructive. The bad news: I found myself constantly thwarted my minor annoyances. The good news: it is clear to me that if we only fixed about a dozen things, Lively could be a true Samurai environment. For that reason I have taken care to document my experiences... S1: It is a real problem to have <save> in the search list (cmd-shift-F) behave differently from in the SCB (System Code Browser). Even if the message tells you that changes are only local, it simply doesn't work to have cooperating tools with different conventions. S2: We must be able to browse old versions of code that we have changed. Yes, one can use the wiki revert mechanism, but it is way too complex and time-consuming, and usually forces you to revert other things that you don't want to change. This is easy to do (see Squeak browse versions) and it will pay off the minute we put it in place. The Samurai knows where he is going and our job is to clear all the obstructions out of his way. S3: I'm convinced there is something wrong with the add/remove method logic in the SCB when you use "sorted" mode. And why wouldn't we use "sorted" all the time? This should be fixed and sorted should be the default. S4 The management of keyboard focus and selections is infuriating. This *has* to be made right. We can't ask a Samurai to keep making his selections over again just because of changing from one window to another. And we can't have cmd-D saving a bookmark instead of evaluating a selection just because keyboard focus isn't treated right. S5: Pan(two-finger) scrolling still does not work right. The rule is very simple: pan scrolling should affect only the innermost scrollable context in which the gesture starts. And it needs to respond immediately. It either works right or it is a distraction. We have enough distractions already. S6: Text frames *must* have adequate margins. We can't ask a Samurai to pick single pixels when trying to select a line of text. S7: The green save message in the SCB does not appear when the method text is scrolled up. If we're going to show it, we should show it, eg, in the middle of the frame as in the Object Editor. S8: We are paying a huge penalty for not having built a scaling pane structure for windows. It must be easy to reshape and position windows on the screen. This should be in the kernel, with a splittable pane in the parts bin. We need a bit of design here, but nothing that hard. S9: For instance it is almost impossible to get a reasonable amount of workspace at the bottom of an inspector. And also on the inspector, arrays longer than 10 or 20 need to be abbreviated, lest they kill the system. S10: It is a huge mistake that we consider syntax errors to be program errors. The Parser should never break and should not cause any program errors (huge red paragraphs splashed all over the screen). If there is a syntax error it should be noted either in the text or with a "before..." or "after..." hint. Why do I call this "huge"? Two reasons. First, the whole job of the parser is to find the errors; why then ask the programmer to find them again without even any help. The second reason comes next... Chris's debugger is really great! I almost started using it all the time. Except that syntax errors are treated as program errors and thus get slowed down by the need to start up the debugger. Let's fix the syntax error problem and all start using the debugger. S11: We need a console window so we can see console messages without having to use the native console. This worked nicely in LK1. S12: The tools have to be fast. I'm talking about inspector, object editor, SCB, search panels, and debugger. It's OK to fetch them from the parts bin once, but they should be cached thereafter. The delay to respond to a change should not be much more than the time it takes the coder to get ready for it. Even for this old Samurai, that's about two seconds. Every one of these obstructions carries a doubled cost. The first is the time wasted; the second is the loss in momentum which is much more costly. I would have (and probably should have) put these all into TRAC, but I think it's important that they be presented as parts of a *gestalt*. If each of these problems is addressed (and most could probably be addressed in a focussed day of work), we will all be working on an entirely new level. It will actually make us better. Even part way through this list, we will be finishing the job faster. Maybe someone could turn this into a Samurai page where we can coordinate this work, or put it into TRAC in a way that the gestalt gets preserved -- maybe by adding a new category of priority called Samurai. I don't want to mess up the current organization, which I think is good. But I do want to establish a distinct new initiative which is to take our coding power to the next level. Let's get busy... _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Hey all,
I have a small addition to S3: when working in sorted mode, folders and files get all mixed up (only sorted alphabetically, but not separated anymore). I personally liked the separation more, so I think it should be possible to preserve it when sorting the lists. Just my point of view. - Benjamin (sorry for the double mail, Dan, I hit the wrong "Answer" button) ________________________________________ Von: [hidden email] [[hidden email]] im Auftrag von Dan Ingalls Gesendet: Montag, 12. März 2012 18:19 An: lively-kernel(mailman) Betreff: [lively-kernel] Samurai coding Folks - Over the weekend i did some Samurai coding. I haven't been able to do much of this recently, but it is very instructive. The bad news: I found myself constantly thwarted my minor annoyances. The good news: it is clear to me that if we only fixed about a dozen things, Lively could be a true Samurai environment. For that reason I have taken care to document my experiences... S1: It is a real problem to have <save> in the search list (cmd-shift-F) behave differently from in the SCB (System Code Browser). Even if the message tells you that changes are only local, it simply doesn't work to have cooperating tools with different conventions. S2: We must be able to browse old versions of code that we have changed. Yes, one can use the wiki revert mechanism, but it is way too complex and time-consuming, and usually forces you to revert other things that you don't want to change. This is easy to do (see Squeak browse versions) and it will pay off the minute we put it in place. The Samurai knows where he is going and our job is to clear all the obstructions out of his way. S3: I'm convinced there is something wrong with the add/remove method logic in the SCB when you use "sorted" mode. And why wouldn't we use "sorted" all the time? This should be fixed and sorted should be the default. S4 The management of keyboard focus and selections is infuriating. This *has* to be made right. We can't ask a Samurai to keep making his selections over again just because of changing from one window to another. And we can't have cmd-D saving a bookmark instead of evaluating a selection just because keyboard focus isn't treated right. S5: Pan(two-finger) scrolling still does not work right. The rule is very simple: pan scrolling should affect only the innermost scrollable context in which the gesture starts. And it needs to respond immediately. It either works right or it is a distraction. We have enough distractions already. S6: Text frames *must* have adequate margins. We can't ask a Samurai to pick single pixels when trying to select a line of text. S7: The green save message in the SCB does not appear when the method text is scrolled up. If we're going to show it, we should show it, eg, in the middle of the frame as in the Object Editor. S8: We are paying a huge penalty for not having built a scaling pane structure for windows. It must be easy to reshape and position windows on the screen. This should be in the kernel, with a splittable pane in the parts bin. We need a bit of design here, but nothing that hard. S9: For instance it is almost impossible to get a reasonable amount of workspace at the bottom of an inspector. And also on the inspector, arrays longer than 10 or 20 need to be abbreviated, lest they kill the system. S10: It is a huge mistake that we consider syntax errors to be program errors. The Parser should never break and should not cause any program errors (huge red paragraphs splashed all over the screen). If there is a syntax error it should be noted either in the text or with a "before..." or "after..." hint. Why do I call this "huge"? Two reasons. First, the whole job of the parser is to find the errors; why then ask the programmer to find them again without even any help. The second reason comes next... Chris's debugger is really great! I almost started using it all the time. Except that syntax errors are treated as program errors and thus get slowed down by the need to start up the debugger. Let's fix the syntax error problem and all start using the debugger. S11: We need a console window so we can see console messages without having to use the native console. This worked nicely in LK1. S12: The tools have to be fast. I'm talking about inspector, object editor, SCB, search panels, and debugger. It's OK to fetch them from the parts bin once, but they should be cached thereafter. The delay to respond to a change should not be much more than the time it takes the coder to get ready for it. Even for this old Samurai, that's about two seconds. Every one of these obstructions carries a doubled cost. The first is the time wasted; the second is the loss in momentum which is much more costly. I would have (and probably should have) put these all into TRAC, but I think it's important that they be presented as parts of a *gestalt*. If each of these problems is addressed (and most could probably be addressed in a focussed day of work), we will all be working on an entirely new level. It will actually make us better. Even part way through this list, we will be finishing the job faster. Maybe someone could turn this into a Samurai page where we can coordinate this work, or put it into TRAC in a way that the gestalt gets preserved -- maybe by adding a new category of priority called Samurai. I don't want to mess up the current organization, which I think is good. But I do want to establish a distinct new initiative which is to take our coding power to the next level. Let's get busy... _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Dan Ingalls-4
Hi, Dan -
thank you, that you took the time to write these issues down. I added them to track and created a new milestone for them The question is now: How to proceed? Some of the issues are clear how to address them, but some are trickier and will take longer to solve. Are there any volunteers to tackle the issues? Best, Jens Am 12.03.2012 um 18:19 schrieb Dan Ingalls:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Had a go at S4 and created a git branch for it:
https://github.com/rksm/LivelyKernel/tree/samurai_fixes Best, Fabian On Wed, Mar 14, 2012 at 5:45 AM, Jens Lincke <[hidden email]> wrote: > Hi, Dan - > > thank you, that you took the time to write these issues down. I added them > to track and created a new milestone for them > http://lively-kernel.org/trac/query?status=assigned&status=new&status=accepted&status=reopened&group=status&milestone=M4+-+Samurai+Coding > > The question is now: How to proceed? Some of the issues are clear how to > address them, but some are trickier and will take longer to solve. > > Are there any volunteers to tackle the issues? > > Best, > Jens > > Am 12.03.2012 um 18:19 schrieb Dan Ingalls: > > Folks - > > Over the weekend i did some Samurai coding. I haven't been able to do much > of this recently, but it is very instructive. > > The bad news: I found myself constantly thwarted my minor annoyances. The > good news: it is clear to me that if we only fixed about a dozen things, > Lively could be a true Samurai environment. For that reason I have taken > care to document my experiences... > > S1: It is a real problem to have <save> in the search list (cmd-shift-F) > behave differently from in the SCB (System Code Browser). Even if the > message tells you that changes are only local, it simply doesn't work to > have cooperating tools with different conventions. > > S2: We must be able to browse old versions of code that we have changed. > Yes, one can use the wiki revert mechanism, but it is way too complex and > time-consuming, and usually forces you to revert other things that you don't > want to change. This is easy to do (see Squeak browse versions) and it will > pay off the minute we put it in place. The Samurai knows where he is going > and our job is to clear all the obstructions out of his way. > > S3: I'm convinced there is something wrong with the add/remove method logic > in the SCB when you use "sorted" mode. And why wouldn't we use "sorted" all > the time? This should be fixed and sorted should be the default. > > S4 The management of keyboard focus and selections is infuriating. This > *has* to be made right. We can't ask a Samurai to keep making his > selections over again just because of changing from one window to another. > And we can't have cmd-D saving a bookmark instead of evaluating a selection > just because keyboard focus isn't treated right. > > S5: Pan(two-finger) scrolling still does not work right. The rule is very > simple: pan scrolling should affect only the innermost scrollable context in > which the gesture starts. And it needs to respond immediately. It either > works right or it is a distraction. We have enough distractions already. > > S6: Text frames *must* have adequate margins. We can't ask a Samurai to > pick single pixels when trying to select a line of text. > > S7: The green save message in the SCB does not appear when the method text > is scrolled up. If we're going to show it, we should show it, eg, in the > middle of the frame as in the Object Editor. > > S8: We are paying a huge penalty for not having built a scaling pane > structure for windows. It must be easy to reshape and position windows on > the screen. This should be in the kernel, with a splittable pane in the > parts bin. We need a bit of design here, but nothing that hard. > > S9: For instance it is almost impossible to get a reasonable amount of > workspace at the bottom of an inspector. And also on the inspector, arrays > longer than 10 or 20 need to be abbreviated, lest they kill the system. > > S10: It is a huge mistake that we consider syntax errors to be program > errors. The Parser should never break and should not cause any program > errors (huge red paragraphs splashed all over the screen). If there is a > syntax error it should be noted either in the text or with a "before..." or > "after..." hint. Why do I call this "huge"? Two reasons. First, the whole > job of the parser is to find the errors; why then ask the programmer to > find them again without even any help. The second reason comes next... > > Chris's debugger is really great! I almost started using it all the time. > Except that syntax errors are treated as program errors and thus get slowed > down by the need to start up the debugger. Let's fix the syntax error > problem and all start using the debugger. > > S11: We need a console window so we can see console messages without having > to use the native console. This worked nicely in LK1. > > S12: The tools have to be fast. I'm talking about inspector, object > editor, SCB, search panels, and debugger. It's OK to fetch them from the > parts bin once, but they should be cached thereafter. The delay to respond > to a change should not be much more than the time it takes the coder to get > ready for it. Even for this old Samurai, that's about two seconds. > > Every one of these obstructions carries a doubled cost. The first is the > time wasted; the second is the loss in momentum which is much more costly. > > I would have (and probably should have) put these all into TRAC, but I think > it's important that they be presented as parts of a *gestalt*. If each of > these problems is addressed (and most could probably be addressed in a > focussed day of work), we will all be working on an entirely new level. It > will actually make us better. Even part way through this list, we will be > finishing the job faster. > > Maybe someone could turn this into a Samurai page where we can coordinate > this work, or put it into TRAC in a way that the gestalt gets preserved -- > maybe by adding a new category of priority called Samurai. I don't want to > mess up the current organization, which I think is good. But I do want to > establish a distinct new initiative which is to take our coding power to the > next level. > > Let's get busy... > _______________________________________________ > lively-kernel mailing list > [hidden email] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > > > > _______________________________________________ > lively-kernel mailing list > [hidden email] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
«
Return to Lively Kernel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |