Recent

Author Topic: How to start? Building Music Tablature notation (text\font based)  (Read 3922 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: How to start?
« Reply #30 on: November 06, 2022, 09:23:12 am »
Right, I'll try to continue that later. However you have to assume that there is a "right sequence" to understand this sort of thing, and that that sequence has been arrived at largely by trial and error over an extended period.

Noting that you're digging into books etc., I'll try to make a few more general points and then stand back for a while.

Computer programming is not maths, in the same way that maths is not arithmetic. Also it's not logic, in the sense that logic is understood by lawyers etc.

Neither is it an art: assumptions that "following ones nose" or "gut feeling" will result in reliable code- code that both works for five minutes and keeps on working if asked to run for hours or months- are almost always unsafe. Hence, in part, the grief I gave you earlier over your "it ought to..." position :-)

Neither is it pure engineering: there are few if any branches of engineering which have not been subjected to robust mathematical analysis and conceptual proof, but software generally stands outside that because of the extreme difficulty of quantifying requirements and behaviour, and the extent to which the complexity of modern components stands outside formal proof (the gates in a CPU are a whisker away from being perturbed by quantum effects).

Pascal, as a language, started off as a one-man project by a compiler writer angered to the point of derangement. By the 1990s the major implementations had matured to be at least as good as other general-purpose languages of the day, but after that it has suffered from an explosion of both good ideas and- to be frank- computer science crap which has left it with (a) some of the more difficult to use concepts sidelined and (b) multiple ways to do quite simple jobs which have been implemented with no regard for efficiency.

Looking at point (a) first, if you refer to older books on Pascal they will show you how to allocate blocks of memory from what is known as the heap, refer to them via pointers, and free them when no longer needed. To a very large extent that has been replaced by the creation of instances of classes which can be referred to like any other variable, you do still need to free them when no longer needed but this is much less painful than the original. (The water is muddied by the fact that there are also objects and advanced records with much the same functionality).

In addition, relatively recent compilers have relaxed some of the ordering requirements: while it is still necessary to declare anything before it is used, there is no longer a requirement that all constants be declared before all types before all variables: by and large that's to be applauded. Don't, however, assume that you can declare a variable inside code (as you can with C/C++ etc.): all declarations have to be /before/ the code block that will use them.

Looking at point (b), Pascal started off with strings of up to 255 characters where each character was a single byte, a string of up to n characters was declared like var something: string[n];. The water has been muddied enormously by the introduction of strings that can not only store more than 255 characters declared like var something: string;, but by the fact that each character might be two or more bytes in order to represent characters outside the original 7-bit US-ASCII range. The result of this is that any attempt to step through such a string one byte at a time will not behave how you want, which is one of the reasons why I have misgivings about your use of a Unicode private area.

There are of course ways round this: several different fundamental character and string types, directives etc. to specify the current codepage when this needs to be known, and a multiplicitly of library functions to protect the user from himself.

On a related point, there are now dynamic arrays which can contain an arbitrary number of elements... plus open arrays, plus ways of retrieving some of the information that the compiler and runtimes use to describe them. They're undoubtedly extremely useful but there's pitfalls... hence in part some of the comments made about certain types of storage being "good up to a 1000 elements or so" earlier.

Now, depending on exactly what books etc. you have available to you, you might or might not find the above points mentioned. Older books- including the foundation Jensen & Wirth which you will at least see referenced- will emphasise manual allocation and deallocation of memory and manual creation of data structures (lists, trees and so on): these are things that you need to know exist, but not ones that you should assume you will be using routinely. Newer books might go overboard about doing absolutely everything by creating small objects and passing them around to mimic the "functional" style of programming: that's all very well, until you start looking at the resultant overheads which might result in something far less efficient than "classical" code. And books focussing on Delphi might give you information on strings which is misleading in the context of Lazarus/FPC.

If in doubt, ask: the community is here to help. But it doesn't like being hectored, and told that something /must/ work and /must/ be the appropriate way when that is quite simply not the case :-)

Hoping that my notes are, to some small extent, useful. If nothing else, print them and use them as bookmarks :-)

MarkMLl
« Last Edit: November 06, 2022, 10:33:52 am by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Emptyself

  • New Member
  • *
  • Posts: 39
Re: How to start?
« Reply #31 on: November 06, 2022, 02:12:55 pm »
Looking at point (a) first, if you refer to older books on Pascal they will show you how to allocate blocks of memory from what is known as the heap, refer to them via pointers, and free them when no longer needed. To a very large extent that has been replaced by the creation of instances of classes which can be referred to like any other variable, you do still need to free them when no longer needed but this is much less painful than the original. (The water is muddied by the fact that there are also objects and advanced records with much the same functionality).
I hope it won't disappoint you if I say that I have next to no idea what you are trying to explain to me here.
Heap pointers? To «free» them? Advanced records?
For now I am trying to understand how my Text Editor displays the cursor, which is also blinking (time).
I an trying to understand the «rectangle» allocation of memory to «host» and «show» me the glyphs on the screen.
In that sense even "Hello, world!" is an 'advanced' topic to me.

Quote
In addition, relatively recent compilers have relaxed some of the ordering requirements: while it is still necessary to declare anything before it is used, there is no longer a requirement that all constants be declared before all types before all variables: by and large that's to be applauded. Don't, however, assume that you can declare a variable inside code (as you can with C/C++ etc.): all declarations have to be /before/ the code block that will use them.
At this moment I do not know how and why to use 'variuables', let alone to 'declare' them in the «block»?!
I think I did understand the topic of 'scope', but that was in a tutorial a few weeks ago. I can not explain it (repeat it) to save my life now…
I hope this speaks how ignorant am I in 'coding'.

Quote
Looking at point (b), Pascal started off with strings of up to 255 characters where each character was a single byte, a string of up to n characters was declared like var something: string[n];. The water has been muddied enormously by the introduction of strings that can not only store more than 255 characters declared like var something: string;, but by the fact that each character might be two or more bytes in order to represent characters outside the original 7-bit US-ASCII range. The result of this is that any attempt to step through such a string one byte at a time will not behave how you want, which is one of the reasons why I have misgivings about your use of a Unicode private area.
OK, I will try to "speak" a bit "professionally" here.
Is or was that 255 limitation because RAM (memory) was tiny back then, so they had to impose such restrictions?
But the font file (Unicode) should not it be just a «map», a «table» or structure of «objects»(?) with instructions («functions»?) on what to be drawn in the "allocated" memory when «a call» of a typing on keyboard is called\detected?

If I can code the «anchor marks» to attach glyphs to glyphs myself in Pascal\LazarusIDE as a set of .svg files, then I would not need a «font» actually. But since in most such Music Notation Editors there is «typing», I thought another «font» file won't hurt or crash the RAM… end it does not have to be "installed" on the System. Only available when the 'program' starts.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: How to start?
« Reply #32 on: November 06, 2022, 02:23:37 pm »
Looking at point (a) first, if you refer to older books on Pascal they will show you how to allocate blocks of memory from what is known as the heap, refer to them via pointers, and free them when no longer needed. To a very large extent that has been replaced by the creation of instances of classes which can be referred to like any other variable, you do still need to free them when no longer needed but this is much less painful than the original. (The water is muddied by the fact that there are also objects and advanced records with much the same functionality).
I hope it won't disappoint you if I say that I have next to no idea what you are trying to explain to me here.

You will, if you find that sort of thing in a book you're reading.

Quote
OK, I will try to "speak" a bit "professionally" here.
Is or was that 255 limitation because RAM (memory) was tiny back then, so they had to impose such restrictions?
But the font file (Unicode) should not it be just a «map», a «table» or structure of «objects»(?) with instructions («functions»?) on what to be drawn in the "allocated" memory when «a call» of a typing on keyboard is called\detected?

It's because originally, each character was represented by a single byte. A Pascal string (declared with an explicit length) reserved element [0] to indicate the current length, that was the same size as the rest of the elements (i.e. one byte) hence had a maximum value of 255.

So if you declared that a particular string should be able to hold 80 bytes, it would always occupy 81 bytes in memory /but/ the current number of valid characters in the string was stored in the zeroeth element.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Emptyself

  • New Member
  • *
  • Posts: 39
Re: How to start?
« Reply #33 on: November 06, 2022, 02:36:26 pm »
So if you declared that a particular string should be able to hold 80 bytes, it would always occupy 81 bytes in memory /but/ the current number of valid characters in the string was stored in the zeroeth element.

MarkMLl

Ah, I think I get that. But why would I need those «strings»? Isn't it more about dealing with «objects», «arrays» and «functions» in computer programming?
Despite the fact a «string» is a 1D array of chars (aren't the latter just 8‑bit chunks from «numerical codes», UTF‑8 → 'Unicode Table Format'), represented by already processed\pre‑rendered in memory «fonts»?


By the way, I added a link to the .pdf file for the 2nd Edition of the book "Oh! Pascal!"* in my original post and here as well: "Oh! Pascal!" (.pdf ~65MB)
*I modified it to be more eye‑friendly for reading from a monitor
« Last Edit: November 06, 2022, 02:42:39 pm by Emptyself »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: How to start?
« Reply #34 on: November 06, 2022, 03:12:32 pm »
Ah, I think I get that. But why would I need those «strings»? Isn't it more about dealing with «objects», «arrays» and «functions» in computer programming?

Might I point out that /you're/ the one who insisted that you wanted to do it like a text editor, despite me and others having misgivings?

I think that the rest of us would agree that what you're likely to need is something like an array with each element comprising a record (in classic Pascal) or object (in newer implementations) which describes pitch, duration, and- crucially- the tempo implied by its separation from its predecessor. But for the moment you're going to be best off trying to get to grips with the underlying language.

In any event, my fairly lengthy note of this morning was intended to alert you to hazards that you're likely to encounter while reading: books which are excessively old will launch into lists, trees and explicit allocation (which you don't need) while books written from the POV of a particular author's research interest will attempt to shoehorn every application into his favoured paradigm (which, again, you don't need).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Emptyself

  • New Member
  • *
  • Posts: 39
Re: How to start?
« Reply #35 on: November 06, 2022, 04:18:29 pm »
Might I point out that /you're/ the one who insisted that you wanted to do it like a text editor, despite me and others having misgivings?
MarkMLl

Not from a design point\perspective, only that "it could be thought of as a 'text editor' on steroids".
It will need play‑cursor, which would have to trigger «sound samples\sprites» every time it (the play‑cursor) passes across notes.

I am sure it will be a steep hill battle… It has been for years, and I still "do not get it", always starting with "Hello, world!", but no one ever explains how and why I am able to type those 'words' and to get my edit\start point on rows using a blinking «caret», how it was made to look like that.
On top of that, no one ever explains why «pixels»?
If I were a hardware manufacturers of display screens, I could have at least try to make te Pixel Pitch size to be a rational fraction of a common unit [mm]. Inch\Feet is more suitable for proportional ratios of big objects such as houses, infrastructure and land.
Yes, I know it is not that easy to go from ⅟₄mm to ⅟₈mm, but it can be ⅟₅, ⅟₆mm.

I just do not get it why do I even have to explain such a simple thing. But fear not, we have "DPI scaling" in Windows, because they have no clue what «optimal minimum size of text is» and how it shold not be referencing the pixels, because those tend to get denser and denser.

https://youtu.be/NF210WeR9C8
Why Microsoft?

Linux as well…
https://youtu.be/zz5qrUVAHX8?t=208

I may have no clue how to program\code but this problem cuold have been solved just right about when MS, Adobe and Apple agreed upon making .ttf a «standard».
« Last Edit: November 06, 2022, 05:55:18 pm by Emptyself »

 

TinyPortal © 2005-2018