7 ms·

I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granula

I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail. Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".

PaulDavisThe1st 4y ago
The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
- 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...

PaulDavisThe1st 4y ago

The point is there isn't really a "thing the program should do". If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic". With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.

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...