Menu
▾
▴
i-score-devs
You can subscribe to this list here.
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(49) |
Oct
(18) |
Nov
(57) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(32) |
Oct
(32) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
(16) |
Feb
(35) |
Mar
(4) |
Apr
(19) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|
From: Pascal B. <pa...@ba...> - 2016-10-25 15:29:45
|
Hi JMC Sorry for chiming in late. > > I'm soon going to merge a big change that allows to use dataspaces in many places in i-score (see attachment). > In the process of doing this, I (voluntarily) broke the save format, since a lot of incorrect stuff was there since ... well a lot of time. Great ! There's no better spring cleaning than those happening in autumn ;-) > > So, first, with some work (a week I guess ?) it is possible to preserve "forward compatibility" (i.e. load old files in new i-score version). All the plug-ins / i-score save "blobs" are versioned, so one 'just' has to implement a function that will, given a save file with version "1", convert it to the format of version "2". But as I said, this is a bit of work and currently I'm not sure I'll have the time to do it. Sure, maybe that’s not top priority, and you probably a lot of other things to do :-) And it’s not as if we had a ten-thousand user-base :-p Maybe that’s something someone can do in the upcoming release project… even if I doubt this will make it high enough on the priority list... > > Then while we're at it, I'd like to know if some people went into the save format and would like some things to change (i.e. let's break everything now so that we don't have to break it again for at least a few years -hopefully-). Would you be able (without too much effort), since you know what changed to make a little scenario using the modified parts, save it in both formats, so we can « diff » and review what’s changed ? I believe that would ease the reviewing/feedback process… best, p |
|
From: Jean-Michaël C. <jea...@gm...> - 2016-10-17 15:53:27
|
Hello everyone, I'm soon going to merge a big change that allows to use dataspaces in many places in i-score (see attachment). In the process of doing this, I (voluntarily) broke the save format, since a lot of incorrect stuff was there since ... well a lot of time. So, first, with some work (a week I guess ?) it is possible to preserve "forward compatibility" (i.e. load old files in new i-score version). All the plug-ins / i-score save "blobs" are versioned, so one 'just' has to implement a function that will, given a save file with version "1", convert it to the format of version "2". But as I said, this is a bit of work and currently I'm not sure I'll have the time to do it. Then while we're at it, I'd like to know if some people went into the save format and would like some things to change (i.e. let's break everything now so that we don't have to break it again for at least a few years -hopefully-). Best regards Jean-Michaël |
|
From: Jean-Michaël C. <jea...@gm...> - 2016-10-17 11:28:26
|
Hello, thanks for your interest ! There are a lot of areas where you could have a look depending on what you're interested. Most of the development is done with the Qt libraries (in the repository https://github.com/OSSIA/i-score), with a small core of pure modern C++ (https://github.com/OSSIA/API) for the execution engine. I put some somewhat easy to do issues here : https://github.com/OSSIA/i-score/labels/Hacktoberfest You may still need to spend some time to dive into the code, feel free to go to the Gitter.im chatroom <https://gitter.im/OSSIA/i-score> if you need some help (and to bash the programmers for the lack of documentation :p). There are also a lot of TODOs in the code, some trivial, some less trivial. More tests are also always welcome :p I am currently working on a *big* patch on the branch OSSIA/i-score:refactor/address_accessors so I would advise starting from here. Best regards, Jean-Michaël On Sat, Oct 15, 2016 at 5:21 PM, John-Michael Faircloth < fai...@gm...> wrote: > Hello, > > I have interest in contributing to your project. I am still relatively new > to C++ (~1.5 yrs). I noticed on your contributing page I could email this > address for info on getting started with contributing. I would appreciate > any information. > > Thanks, > > John-Michael Faircloth > fai...@gm... > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs > |
|
From: John-Michael F. <fai...@gm...> - 2016-10-15 15:21:09
|
Hello, I have interest in contributing to your project. I am still relatively new to C++ (~1.5 yrs). I noticed on your contributing page I could email this address for info on getting started with contributing. I would appreciate any information. Thanks, John-Michael Faircloth fai...@gm... |
|
From: Pascal B. <pa...@ba...> - 2016-10-13 14:52:45
|
Hi there ! Je viens de voir passer ça sur la liste OSCquery : > http://thewizardofosc.com/ <http://thewizardofosc.com/> Bon, ils en rajoutent un peu sur l’innovation du truc, mais au moins ça paraît assez robuste et avec une interface un peu user-friendly… C’était la petite veille du jour. À bientôt, p |
|
From: Pascal B. <pa...@ba...> - 2016-05-26 09:17:16
|
>> however, I can't select a device's node to record all its parameters at once. > Yep, this is on the to-do list... (as well as play-back during recording but that's a hard one). Do you think that this part of the todo-list would be doable in the next month ? I’m planning to use i-score to work again on Nebula’s scenario next month, and it would be AWESOME to be able to have playback while recording... |
|
From: Antoine V. <ant...@gm...> - 2016-05-25 12:14:11
|
ok cool, in the meanwhile, as a workaround, one can unfold the device tree and select all adjacent parameters with Shift + Click. but it seems that recording lots of parameters hangs i-score (at least on an old mac mini 3,1, core 2 duo 2,6GHz) best a -- do it yourself http://antoine.villeret.free.fr 2016-05-25 12:57 GMT+02:00 Jean-Michaël Celerier < jea...@gm...>: > > On Wed, May 25, 2016 at 12:38 PM, Antoine Villeret < > ant...@gm...> wrote: > >> however, I can't select a device's node to record all its parameters at >> once. >> > > Yep, this is on the to-do list... (as well as play-back during recording > but that's a hard one). > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs > > |
|
From: Jean-Michaël C. <jea...@gm...> - 2016-05-25 10:58:46
|
On Wed, May 25, 2016 at 12:38 PM, Antoine Villeret < ant...@gm...> wrote: > however, I can't select a device's node to record all its parameters at > once. > Yep, this is on the to-do list... (as well as play-back during recording but that's a hard one). |
|
From: Antoine V. <ant...@gm...> - 2016-05-25 10:39:33
|
Hey, thanks a lot, I was sure this is possible, and it is awesome ! :-) (I had some crashes btw, see https://github.com/OSSIA/i-score/issues/184) however, I can't select a device's node to record all its parameters at once. Instead I have to select each parameter one by one, which is quite annoying since I have more than 1000 parameters to record :-) Is there a workaround I missed ? Thanks Antoine -- do it yourself http://antoine.villeret.free.fr 2016-05-24 21:29 GMT+02:00 Jean-Michaël Celerier < jea...@gm...>: > Hi Antoine :) > > Yep : select the parameters you want to record, right-click in the > scenario, and choose Record. > > There are currently two ways to record (plus options in the settings) : > - one that will record and replay the value of parameters and create > corresponding automations / interpolations. > It's only available with int and float addresses. > - one that will record all input messages and just replay them. > It's available with all types of addresses (but is not well tested and > recorded data cannot be changed afterwards). > > > Best, > Jean-Michaël > > > On Tue, May 24, 2016 at 5:05 PM, Antoine Villeret < > ant...@gm...> wrote: > >> Hi list, >> >> Is it possible to use i-score to record Minuit parameter changes ? >> like a sequencer would do ? >> if yes, how can I do that with i-score 1.0.0-a66 ? >> >> thanks >> >> antoine >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> ------------------------------------------------------------------------------ >> Mobile security can be enabling, not merely restricting. Employees who >> bring their own devices (BYOD) to work are irked by the imposition of MDM >> restrictions. Mobile Device Manager Plus allows you to control only the >> apps on BYO-devices by containerizing them, leaving personal data >> untouched! >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs >> >> > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs > > |
|
From: Jean-Michaël C. <jea...@gm...> - 2016-05-24 19:30:02
|
Hi Antoine :) Yep : select the parameters you want to record, right-click in the scenario, and choose Record. There are currently two ways to record (plus options in the settings) : - one that will record and replay the value of parameters and create corresponding automations / interpolations. It's only available with int and float addresses. - one that will record all input messages and just replay them. It's available with all types of addresses (but is not well tested and recorded data cannot be changed afterwards). Best, Jean-Michaël On Tue, May 24, 2016 at 5:05 PM, Antoine Villeret < ant...@gm...> wrote: > Hi list, > > Is it possible to use i-score to record Minuit parameter changes ? > like a sequencer would do ? > if yes, how can I do that with i-score 1.0.0-a66 ? > > thanks > > antoine > -- > do it yourself > http://antoine.villeret.free.fr > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs > > |
|
From: Antoine V. <ant...@gm...> - 2016-05-24 15:06:36
|
Hi list, Is it possible to use i-score to record Minuit parameter changes ? like a sequencer would do ? if yes, how can I do that with i-score 1.0.0-a66 ? thanks antoine -- do it yourself http://antoine.villeret.free.fr |
|
From: Théo de la H. <the...@gm...> - 2016-04-12 13:03:05
|
Hi ! I’ll be glad to be part of this discussion as a quiet listener reminding sometimes why we did some choices that can be not obvious for people who don’t have the whole story. Best, TO > Le 12 avr. 2016 à 14:23, Pascal Baltazar <pa...@ba...> a écrit : > > Absolutely agree with all you said, Trond ! > > A skype session with the four of us would be a good start. Of course meeting physically would be even better… > > Cheers ! > > p > > >> Le 11 avr. 2016 à 09:47, Trond Lossius <tro...@be...> a écrit : >> >> I believe the key thing about design is that good design helps you use the tools in the best possible way, in other words good design gives the tools good affordance. This includes having the information available to you that you need (but not info that you don’t need), and having information layed out in a way that direct your intention towards the essential information, and that don’t strain you when working with it for prolonged periods of time. >> >> Sometimes this may mean very minimal interfaces, and at other times they’ll be complex. i-score probably need a bit of both - the score itself should present the outline of the score in a clean way that helps you getting an overview while also accessing and asserting the details of it. The inspectors obviously will be more complex, but even then, if they are designed well, they are accessible, and when they are not designed well it may make the whole application inaccessible. >> I believe that e.g. thinking of interaction with inspectors as stories may help improving the layout. >> >> If possible it would be very useful to have a session where Jean Michael and Stian Remvik could sit down together, Stian is really good at critically reviewing design for functionality. One hour with him prior to the release of the new version of the Jamoma web site probably improved the structure of the site by 40-50%. >> >> Best, >> Trond >> >> >> >> >>> On 07 Apr 2016, at 13:30, Pascal Baltazar <pa...@ba...> wrote: >>> >>> :-) >>> >>>> https://m.signalvnoise.com/why-i-love-ugly-messy-interfaces-and-you-probably-do-too-edff4a896a83#.p9yuw33b7 >> >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications Manager >> Applications Manager provides deep performance insights into multiple tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ >> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-12 12:24:28
|
> Le 11 avr. 2016 à 10:00, Trond Lossius <tro...@be...> a écrit : > > In user interaction design, I believe that minus signs typically indicates that something can be collapsed to show less information. “x” is the common way of indicating that something can be crossed out or deleted. right ! > > And it should be at the right hand side, not the left. sorry, my mistake, it’s on the right side p > > Best, > Trond > > >> On 07 Apr 2016, at 13:18, Pascal Baltazar <pa...@ba...> wrote: >> >> There’s a little minus sign on the left - is that visible enough for you ? >> >>> Le 7 avr. 2016 à 13:06, Trond Lossius <tro...@be...> a écrit : >>> >>> Hi, >>> >>> Not having them makes sense to me as well. If there’s a simple way of deleting a condition (e.g. a trash can icon or an X), that would ideally be enough. >>> >>> Best, >>> Trond >>> >>> >>> >>>> On 07 Apr 2016, at 12:06, Pascal Baltazar <pa...@ba...> wrote: >>>> >>>> Hi ! >>>> >>>> We’ve discussed this in the past, and my opinion was that they shouldn’t be there at all. >>>> I don’t see any reason for confirming (or canceling) once the adress and expression are set… >>>> Though, I think there was a technical issue that forced to use this… in which case, I agree it’s better that they are placed below… >>>> >>>> Best, >>>> >>>> p >>>> >>>>> Le 7 avr. 2016 à 09:57, Trond Lossius <tro...@be...> a écrit : >>>>> >>>>> Hi, >>>>> >>>>> I’d like to suggest a slight change to the Condition inspector, currently looking like this: >>>>> >>>>> <Screen Shot 2016-04-07 at 09.49.55.png> >>>>> >>>>> If you think of how the user interacts with this as a story it probably goes something like: >>>>> >>>>> - I choose what parameter to use, what the condition is tone, and what the threshold value should be, and then I hit OK. >>>>> >>>>> In following with this I believe that OK and Cancel should be below, not above the setting up of the condition. The current structure is a bit as if my mail app dialog boxes looked like this: >>>>> >>>>> >>>>> >>>>> <Screen Shot 2016-04-07 at 09.52.05.png> >>>>> >>>>> >>>>> Best, >>>>> Trond >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> I-score-devs mailing list >>>>> I-s...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> I-score-devs mailing list >>>> I-s...@li... >>>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> I-score-devs mailing list >>> I-s...@li... >>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ > gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-12 12:23:45
|
Absolutely agree with all you said, Trond ! A skype session with the four of us would be a good start. Of course meeting physically would be even better… Cheers ! p > Le 11 avr. 2016 à 09:47, Trond Lossius <tro...@be...> a écrit : > > I believe the key thing about design is that good design helps you use the tools in the best possible way, in other words good design gives the tools good affordance. This includes having the information available to you that you need (but not info that you don’t need), and having information layed out in a way that direct your intention towards the essential information, and that don’t strain you when working with it for prolonged periods of time. > > Sometimes this may mean very minimal interfaces, and at other times they’ll be complex. i-score probably need a bit of both - the score itself should present the outline of the score in a clean way that helps you getting an overview while also accessing and asserting the details of it. The inspectors obviously will be more complex, but even then, if they are designed well, they are accessible, and when they are not designed well it may make the whole application inaccessible. > I believe that e.g. thinking of interaction with inspectors as stories may help improving the layout. > > If possible it would be very useful to have a session where Jean Michael and Stian Remvik could sit down together, Stian is really good at critically reviewing design for functionality. One hour with him prior to the release of the new version of the Jamoma web site probably improved the structure of the site by 40-50%. > > Best, > Trond > > > > >> On 07 Apr 2016, at 13:30, Pascal Baltazar <pa...@ba...> wrote: >> >> :-) >> >>> https://m.signalvnoise.com/why-i-love-ugly-messy-interfaces-and-you-probably-do-too-edff4a896a83#.p9yuw33b7 > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ > gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Trond L. <tro...@be...> - 2016-04-11 08:00:54
|
In user interaction design, I believe that minus signs typically indicates that something can be collapsed to show less information. “x” is the common way of indicating that something can be crossed out or deleted. And it should be at the right hand side, not the left. Best, Trond > On 07 Apr 2016, at 13:18, Pascal Baltazar <pa...@ba...> wrote: > > There’s a little minus sign on the left - is that visible enough for you ? > >> Le 7 avr. 2016 à 13:06, Trond Lossius <tro...@be...> a écrit : >> >> Hi, >> >> Not having them makes sense to me as well. If there’s a simple way of deleting a condition (e.g. a trash can icon or an X), that would ideally be enough. >> >> Best, >> Trond >> >> >> >>> On 07 Apr 2016, at 12:06, Pascal Baltazar <pa...@ba...> wrote: >>> >>> Hi ! >>> >>> We’ve discussed this in the past, and my opinion was that they shouldn’t be there at all. >>> I don’t see any reason for confirming (or canceling) once the adress and expression are set… >>> Though, I think there was a technical issue that forced to use this… in which case, I agree it’s better that they are placed below… >>> >>> Best, >>> >>> p >>> >>>> Le 7 avr. 2016 à 09:57, Trond Lossius <tro...@be...> a écrit : >>>> >>>> Hi, >>>> >>>> I’d like to suggest a slight change to the Condition inspector, currently looking like this: >>>> >>>> <Screen Shot 2016-04-07 at 09.49.55.png> >>>> >>>> If you think of how the user interacts with this as a story it probably goes something like: >>>> >>>> - I choose what parameter to use, what the condition is tone, and what the threshold value should be, and then I hit OK. >>>> >>>> In following with this I believe that OK and Cancel should be below, not above the setting up of the condition. The current structure is a bit as if my mail app dialog boxes looked like this: >>>> >>>> >>>> >>>> <Screen Shot 2016-04-07 at 09.52.05.png> >>>> >>>> >>>> Best, >>>> Trond >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> I-score-devs mailing list >>>> I-s...@li... >>>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> I-score-devs mailing list >>> I-s...@li... >>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Trond L. <tro...@be...> - 2016-04-11 07:53:44
|
I’ve just found a useful free app that simulates various kinds of colour-blindness: Sim Daltonism. It’s available for free at the App Store: https://itunes.apple.com/us/app/sim-daltonism/id693112260?mt=12 Using it it seems to me that it is hard to distinguish green and aqua for several varieties of colour-blindness It would probably be a good utility to use in future design, not only of i-score, but also Jamoma. Best, Trond > On 07 Apr 2016, at 12:16, Pascal Baltazar <pa...@ba...> wrote: > > Agreed ! > > p > >> Le 6 avr. 2016 à 22:58, Trond Lossius <tro...@be...> a écrit : >> >> Hi, >> >> Another usability observation: >> >> I find that if the i-score window is small, the blue and green colour used along the lines between time constrains while playing look pretty similar, and are not all that easy to distinguish. Take a quick glance at the screenshot below and see if it immediately springs at you where we are in time in this screen shot. >> >> <Screen Shot 2016-04-06 at 22.38.54.png> >> >> Additionally I am concerned that the green and blue colours may be even more similar to some colour blind users, if they are unable to distinguish between green and blue. >> >> I would recommend not to use a change in colour hue to signal progress in time. Typically differences in colour hue indicates difference in the kind of information that is to be communicated - see e.g. the different colours available in bootstrap for buttons and how they are meant to communicate different classes of information: >> >> http://www.w3schools.com/bootstrap/bootstrap_buttons.asp >> >> Instead I would suggest using a differentiation in saturation and brightness, and you can also alter how thick the line is, as is currently being done.For example a line segment can be a certain colour initially, as one is venturing into it the part that is playing becomes brighter, and when it is all done and not active any linger it can become darker, as in deactivated / no longer active. Here’s a quick mockup that probably could be refined a lot. The idea here is that we re done playing the first time segment, and we’re halfway through the second one. >> >> <Screen Shot 2016-04-06 at 22.53.57.png> >> >> >> Best, >> Trond >> ------------------------------------------------------------------------------ >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Trond L. <tro...@be...> - 2016-04-11 07:48:01
|
I believe the key thing about design is that good design helps you use the tools in the best possible way, in other words good design gives the tools good affordance. This includes having the information available to you that you need (but not info that you don’t need), and having information layed out in a way that direct your intention towards the essential information, and that don’t strain you when working with it for prolonged periods of time. Sometimes this may mean very minimal interfaces, and at other times they’ll be complex. i-score probably need a bit of both - the score itself should present the outline of the score in a clean way that helps you getting an overview while also accessing and asserting the details of it. The inspectors obviously will be more complex, but even then, if they are designed well, they are accessible, and when they are not designed well it may make the whole application inaccessible. I believe that e.g. thinking of interaction with inspectors as stories may help improving the layout. If possible it would be very useful to have a session where Jean Michael and Stian Remvik could sit down together, Stian is really good at critically reviewing design for functionality. One hour with him prior to the release of the new version of the Jamoma web site probably improved the structure of the site by 40-50%. Best, Trond > On 07 Apr 2016, at 13:30, Pascal Baltazar <pa...@ba...> wrote: > > :-) > >> https://m.signalvnoise.com/why-i-love-ugly-messy-interfaces-and-you-probably-do-too-edff4a896a83#.p9yuw33b7 |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 11:30:44
|
:-) > https://m.signalvnoise.com/why-i-love-ugly-messy-interfaces-and-you-probably-do-too-edff4a896a83#.p9yuw33b7 <https://m.signalvnoise.com/why-i-love-ugly-messy-interfaces-and-you-probably-do-too-edff4a896a83#.p9yuw33b7> |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 11:18:54
|
There’s a little minus sign on the left - is that visible enough for you ? > Le 7 avr. 2016 à 13:06, Trond Lossius <tro...@be...> a écrit : > > Hi, > > Not having them makes sense to me as well. If there’s a simple way of deleting a condition (e.g. a trash can icon or an X), that would ideally be enough. > > Best, > Trond > > > >> On 07 Apr 2016, at 12:06, Pascal Baltazar <pa...@ba...> wrote: >> >> Hi ! >> >> We’ve discussed this in the past, and my opinion was that they shouldn’t be there at all. >> I don’t see any reason for confirming (or canceling) once the adress and expression are set… >> Though, I think there was a technical issue that forced to use this… in which case, I agree it’s better that they are placed below… >> >> Best, >> >> p >> >>> Le 7 avr. 2016 à 09:57, Trond Lossius <tro...@be...> a écrit : >>> >>> Hi, >>> >>> I’d like to suggest a slight change to the Condition inspector, currently looking like this: >>> >>> <Screen Shot 2016-04-07 at 09.49.55.png> >>> >>> If you think of how the user interacts with this as a story it probably goes something like: >>> >>> - I choose what parameter to use, what the condition is tone, and what the threshold value should be, and then I hit OK. >>> >>> In following with this I believe that OK and Cancel should be below, not above the setting up of the condition. The current structure is a bit as if my mail app dialog boxes looked like this: >>> >>> >>> >>> <Screen Shot 2016-04-07 at 09.52.05.png> >>> >>> >>> Best, >>> Trond >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> I-score-devs mailing list >>> I-s...@li... >>> https://lists.sourceforge.net/lists/listinfo/i-score-devs >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Trond L. <tro...@be...> - 2016-04-07 11:06:52
|
Hi, Not having them makes sense to me as well. If there’s a simple way of deleting a condition (e.g. a trash can icon or an X), that would ideally be enough. Best, Trond > On 07 Apr 2016, at 12:06, Pascal Baltazar <pa...@ba...> wrote: > > Hi ! > > We’ve discussed this in the past, and my opinion was that they shouldn’t be there at all. > I don’t see any reason for confirming (or canceling) once the adress and expression are set… > Though, I think there was a technical issue that forced to use this… in which case, I agree it’s better that they are placed below… > > Best, > > p > >> Le 7 avr. 2016 à 09:57, Trond Lossius <tro...@be...> a écrit : >> >> Hi, >> >> I’d like to suggest a slight change to the Condition inspector, currently looking like this: >> >> <Screen Shot 2016-04-07 at 09.49.55.png> >> >> If you think of how the user interacts with this as a story it probably goes something like: >> >> - I choose what parameter to use, what the condition is tone, and what the threshold value should be, and then I hit OK. >> >> In following with this I believe that OK and Cancel should be below, not above the setting up of the condition. The current structure is a bit as if my mail app dialog boxes looked like this: >> >> >> >> <Screen Shot 2016-04-07 at 09.52.05.png> >> >> >> Best, >> Trond >> ------------------------------------------------------------------------------ >> _______________________________________________ >> I-score-devs mailing list >> I-s...@li... >> https://lists.sourceforge.net/lists/listinfo/i-score-devs > > > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 10:18:37
|
+1 ! > Le 6 avr. 2016 à 23:04, Trond Lossius <tro...@be...> a écrit : > > Hi, > > Midway through Tutorial 2, we find the following text: > > “Now, click on the Time Constraint between these two states, and, on the top toolbar, press « Interpolate States ».” > > IMHO it would be useful if Interpolate States would also show up on a contextual menu when right-clicking with the mouse over the time constraint. > > Best, > Trond > > > > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 10:16:46
|
Agreed ! p > Le 6 avr. 2016 à 22:58, Trond Lossius <tro...@be...> a écrit : > > Hi, > > Another usability observation: > > I find that if the i-score window is small, the blue and green colour used along the lines between time constrains while playing look pretty similar, and are not all that easy to distinguish. Take a quick glance at the screenshot below and see if it immediately springs at you where we are in time in this screen shot. > > <Screen Shot 2016-04-06 at 22.38.54.png> > > Additionally I am concerned that the green and blue colours may be even more similar to some colour blind users, if they are unable to distinguish between green and blue. > > I would recommend not to use a change in colour hue to signal progress in time. Typically differences in colour hue indicates difference in the kind of information that is to be communicated - see e.g. the different colours available in bootstrap for buttons and how they are meant to communicate different classes of information: > > http://www.w3schools.com/bootstrap/bootstrap_buttons.asp <http://www.w3schools.com/bootstrap/bootstrap_buttons.asp> > > Instead I would suggest using a differentiation in saturation and brightness, and you can also alter how thick the line is, as is currently being done.For example a line segment can be a certain colour initially, as one is venturing into it the part that is playing becomes brighter, and when it is all done and not active any linger it can become darker, as in deactivated / no longer active. Here’s a quick mockup that probably could be refined a lot. The idea here is that we re done playing the first time segment, and we’re halfway through the second one. > > <Screen Shot 2016-04-06 at 22.53.57.png> > > > Best, > Trond > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 10:13:10
|
Hi ! > > Would it be possible to extend the scrollbars in i-score with small handles at the end that could be used to click and drag zoom-in and zoom-out? Reaper behaves this way as illustrated in the below screencast. agreed, that would be nice ! can you add an issue on github for that ? > > Additionally, when holding the cursor over the horisontal (time) scrollbar and pinching/zooming at the trackpad, or using the scroll wheel, it would be nice if this also would be zooming in and out in time rather than scrolling up and down. you can do that with cmd-scroll > > And a third request: When creating a new i-score at a 15” macbook, and bringing the application to full screen, the time canvas initially show the first 3 minutes of the score. Could this be zoomed in by default to e.g. the first 20 seconds? Currently when creating a first time constraint, that typically ends up being at 25 seconds. Even for me, fond as I am of ambient and minimalist music, that’s a long while to wait for the first thing to happen in the score. I agree the scenario should be zoomed in to ±30sec by default - BTW, what do you think of 3 minutes as default lenght of the scenario ? If we zoom in by default, I would rather have a 10 min default length, os something like that… (anyway, it’s very simple to extend it) > > In previously stored score the final time selection from the last session could be saved with the file, so that it opens back up to the same state as last time, but for new scores I would guess that you don’ts tart straight away with outlining events over several minutes, but rather make your way from the start towards later events step by step. I’m not sure I understand what you mean here... > > Thanks for considering it. One thing to consider is that, from now on, there is no developer allocated fulltime on i-score, only Jean-Mickaël will do aside of his PhD, so he doesn’t have a lot of time… Though, we’ve been discussing in Albi switching the interface design to QML, which is a kind of javascript-ish way to design the interface… so that we, users, could more easily modify things in lack of developers… and that it could ease contributions... Cheers, Pascam > > Best, > Trond > > > <i-score scrollbar.mp4>------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Pascal B. <pa...@ba...> - 2016-04-07 10:06:36
|
Hi ! We’ve discussed this in the past, and my opinion was that they shouldn’t be there at all. I don’t see any reason for confirming (or canceling) once the adress and expression are set… Though, I think there was a technical issue that forced to use this… in which case, I agree it’s better that they are placed below… Best, p > Le 7 avr. 2016 à 09:57, Trond Lossius <tro...@be...> a écrit : > > Hi, > > I’d like to suggest a slight change to the Condition inspector, currently looking like this: > > <Screen Shot 2016-04-07 at 09.49.55.png> > > If you think of how the user interacts with this as a story it probably goes something like: > > - I choose what parameter to use, what the condition is tone, and what the threshold value should be, and then I hit OK. > > In following with this I believe that OK and Cancel should be below, not above the setting up of the condition. The current structure is a bit as if my mail app dialog boxes looked like this: > > > > <Screen Shot 2016-04-07 at 09.52.05.png> > > > Best, > Trond > ------------------------------------------------------------------------------ > _______________________________________________ > I-score-devs mailing list > I-s...@li... > https://lists.sourceforge.net/lists/listinfo/i-score-devs |
|
From: Trond L. <tro...@be...> - 2016-04-07 08:11:38
|
Hi, I just experienced a crash while testing out branching according to the instructions at the end of tutorial 3. I’m attaching the log and the recovered score. Best, Trond |
5 messages has been excluded from this view by a project administrator.
