Jump to content

Patch Editor for NTS-1 Project - Part 01


k-Pack

56 views

 Share

Getting Started:

 

Been thinking long and hard about programming a patch editor for the Korg NTS-1 synth.  There are patch editors out there, but none will output the Continuous Controllers (CC#) as program change commands used in the MIDI MUSIC SYSTEM (MMS) voice file format.

 

Since I'm aware that I may be the only person to use this program, I have decided to write the program in assembly (MAC65) to run using the Diamond GOS 3. I should be able to write the code in stages and test as I go.  This is going to take a greater amount of preplanning and am hoping to avoid the helter-skelter approach normally used when I program in BASIC.

 

I know that there will never be a spit-n-polished version. I'm not delusional enough to believe that Korg will ever add it to their catalog.

 

I am going to blog as the plan is executed. It may be of interest to those that want to develop Diamond programs.   Dialog boxes, the Dropdown menu, icons and the event handler will all be used in the program.  The Diamond 3.0's internal File Select routine will be used; one of those Diamond macros that can never have enough examples.

 

There might be a little bit of 2-byte math, limited to screen positioning.  MIDI is all done with 8-bit numbers with much of it limited to 7 bits.     I like that.

 

The biggest problem is how to handle the lack of a 5pin-Din MIDI output from the NTS-1.  If the knobs are adjusted on the NTS-1 the Atari will never know.

 

If the program can output the CC# values to the NTS-1, save the set of numbers that define the patch, and load the values for later use, then it will be of some use.  If it does that and is compatible with MMS , I will feel the time I put into this project is well spent.

 

The second problem is discovering what I need to relearn about Diamond programing after a 4-year hiatus.  

 

 

Step 1

 

Always my first step is to build and test the Info Dialog box.  It gives me something to do while I think about screen designs and drop-down menu options. It also gives an idea on how much Diamond knowledge has been forgotten over the last 4 years.  The "How to build a Simple Info Dialog Box" sheet was Greek to me. By the time the Dialog box was correctly displayed, the sheet made perfect sense.

 

Seeing the program title on the screen also symbolizes a commitment to see the project to the end.

 

1176221407_InfoDialogbox.JPG.7d58b5eaef32ac2182e49de3a5709248.JPG

 

 

DLOGTEST.M65 is the source code to display the "Info…." dialog box.  Running the DLOGTEST.APP will show the program information.  Click anywhere within the box to exit back to the desktop.

 

INFODLOG.M65 is the DLOGTEST.M65 modified to be a subroutine.  This subroutine will be #INCLUDEd in the program in hopes of keeping program versions form together.

 

DMACRO01.M65 is the set of Diamond macros, some of which I have modified for various reasons.  Check back in the blog for why changes have been made. And to check my logic. 

 

 

Step 2

 

Building the drop-down menu and starting to develop the EVENT logic is going to be the start for many test routines.  I already know that the Note and Octave categories should be removed if possible.

 

1688327858_IMG_0140(2).thumb.JPG.559966be131a45a9a825d5797d66cecf.JPG

 

In this test the Desk-INF… will display the Info dialog box and the FILE-QUIT option takes you back to the desktop.  All other program  options have been defined as inactive.  The LOAD and SAVE options look inactive only because the MENUENABLE macro prints them in italic.  Also MENUCHECK was used to indicate the current setting for Channel, Note, and Octave.

 

MENUTEST.M65, MENUTESTAPP.  It’s a start. 

 

nts1 blog1.atr

 

What's next:

 

Get the MIDI data flowing through the MIDI port out to the NTX-1.  This way I can tell if any future additions to the program interfere with the data as they are added. I know that the ICON event returns the X,Y position of the mouse but not so sure if they are in reference to the screen or within the icon?

 

Also, I need to start thinking of the ICONs in groups of objects that share attributes and methods.  Should be easier to write subroutines, if they all share the same data structure.  I think there's a name for that.  

 Share

0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...