6 ms·

It's still "enter data/modify data" along with suitable UI/ux and views to enable that. Of course a DAW can probably be viewed as a low code tool for programmi

by e12e 4y ago

It's still "enter data/modify data" along with suitable UI/ux and views to enable that. Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet. Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track. The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".

PaulDavisThe1st 4y ago
"Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc. > It's still "enter data/modify data" along with suitable UI/ux and views to enable that. While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful. > Still, the user has a goal, a process of achieving that goal This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."
- e12e 4y ago
  > "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. Wikipedia gives the following definition for "business logic" > In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. I (and i believe op) lean on the "domain logic" end when talking about business logic. So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts. > Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
  - PaulDavisThe1st 4y ago
    From the wiki quote: > the real-world business rules what are these for creative apps, and where do they come from?
    - e12e 4y ago
      > ... determine how data can be created, stored, and changed. So you can record sound, store it in a "track", transform it to "mono" etc? > ... It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. You might store the sound as a wav, export it as an mp3 - the undo tree might be in SQLite... Ed: might make more sense with the term "domain"; domain logic, domain rules. Ed2: somewhat tangential, but see also the original model-view-controller-(user) paper - the user holds a mental model of data/objects in the domain - and the application holds raw data in ram/disk - the UI needs to bridge these two domains so that a user can "apply reverb" from the domain concept to the actual data model (modify a wav file). https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
- deleted 4y ago
  [deleted]

by e12e 4y ago

PaulDavisThe1st 4y ago

"Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc. > It's still "enter data/modify data" along with suitable UI/ux and views to enable that. While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful. > Still, the user has a goal, a process of achieving that goal This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."

e12e 4y ago
> "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values. Wikipedia gives the following definition for "business logic" > In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. I (and i believe op) lean on the "domain logic" end when talking about business logic. So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts. > Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
- PaulDavisThe1st 4y ago
  From the wiki quote: > the real-world business rules what are these for creative apps, and where do they come from?
  - e12e 4y ago
    > ... determine how data can be created, stored, and changed. So you can record sound, store it in a "track", transform it to "mono" etc? > ... It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. You might store the sound as a wav, export it as an mp3 - the undo tree might be in SQLite... Ed: might make more sense with the term "domain"; domain logic, domain rules. Ed2: somewhat tangential, but see also the original model-view-controller-(user) paper - the user holds a mental model of data/objects in the domain - and the application holds raw data in ram/disk - the UI needs to bridge these two domains so that a user can "apply reverb" from the domain concept to the actual data model (modify a wav file). https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
deleted 4y ago
[deleted]