Recent Posts

Pages: 1 [2] 3 4 ... 10
11
MPW isn't a IDE, it's a shell (and a cumbersome one as well) but it filled a purpose in particular if you had build servers and wanted to automate stuff.

What qualifies as an IDE then? MPW is definitely an IDE.

Ok correction, MPW is not an IDE by my definition as an IDE typically is made to accelerate the development process by providing by the very least automatic project management and build automation.

But yeah okay, if MPW qualify as an IDE, then I guess Terminal.app, command.com etc are IDEs too. Or rather what would define something not to be an IDE then?
12
the entire point of this post was to urge the use of .img apple disk image files (NDIF)
BECAUSE they are compatible on all versions of OSX + almost all flavours of classic Mac OS (7.x, 8.x, 9.x)

newer INTEL versions of OSX require you to convert the .img to a .dmg in disk utility, but as long as u do this
they are still 100% compatible but the PPC versions of OSX (up to 10.5) i believe can still natively mount .img files

the whole point being to reduce and end the possibility of STUFFIT + UNARCHIVER *ERRORS* that occur
frequently when one opens a file on a different  machine/os combination - incompatibilities arise in stuffit file formats
and certain file metadata is lost (such as correct title/names or dates) when the files are unarchived improperly
(as such is often the case when mac files are put inside a .zip file and unzipped on diff computer)
13
DAW - Digital Performer by MOTU / Re: Unisyn 1.5
« Last post by macStuff on November 20, 2017, 06:10:09 PM »
http://lists.cloudfactory.org/pipermail/motu-mac/2000-September/010565.html
according to this page, 1.52 was already out as of (Sep 2000) so the v1.52 update date must be before that time
maybe in early 2000? or late 1999?


checking this image carefully does show a copyright date of 1999!

http://www.cloudfactory.org/pipermail/motu-mac/2000-November/016799.html
this page claims :

Quote
Because of PACE, you have to get installer CD from MOTU.
Because of PACE, Uni 1.52 is not a patch release.
Read on...
so i guess thats why i cant find an update patcher file for unisyn v1.5 to unisyn v1.52

you need the entire unisyn 1.52 cd! does anyone here have a copy?
14
DAW - Digital Performer by MOTU / Re: Unisyn 1.5
« Last post by macStuff on November 20, 2017, 04:34:39 PM »
checking the requirements for unisyn v1.5 i see the followng:
http://www.motu.com/techsupport/technotes/unisyn-1.5-system-requirements
Quote
System Requirements for Unisyn 1.5

Unisyn version 1.5 has the following system requirements:

For Mac:
2 MB RAM or more
Mac OS version 7.1 to 9.2.2; Mac OS X is not supported (Unisyn version 2.1 is required)

For Windows:
IBM PC or compatible
MIDI driver installed for MIDI interface which will be used with Unisyn
Windows 3.1, 95, 98, ME, or 2000; Windows XP and later are not supported

the requirements for unisyn v2.0 also say its compatible with mac os7-9
http://www.motu.com/techsupport/technotes/unisyn-2-system-requirements/
so, it seems that BOTH v1.5 + v2.0 are for macos7-9
so im assuming that one could use EITHER VERSION..

do any experienced users know any reason NOT to use Unisyn 1.5?
is there any compatibility issues?
does anyone know when unisyn v1.5 was updated to v1.52?
was this a modern update? (in the era of 9.22) or a not so modern update? (prior to mac os 9 release)

from checking facts, i can see that Unisyn v2.02 was released in (March 2003)
15
funny this thread ended up being about SVP, when that wasnt even in the original post ;)

im still surprised many here on this site have next to nothing to say about Ableton Live 4.14!
which is the most recently updated app available for mac os 9, after Logic Bailed on mac os 9
ableton held out till mid 2005 i think.. and still supported mac os 9 even after the intel macs were
rolled out!
16
http://www.motu.com/techsupport/technotes/document.1998-10-28.5507466655
this technote details the process of setting up the Opcode Studio 5 (or Studio 4) to use MOTU's FreeMIDI
as discussed in the above article from oct 1996
17
taken from the oms_freemidi.pdf file found here: http://www.sibelius.com/helpcenter/resources/oms_freemidi.pdf

Quote
Setting up FreeMIDI in OMS compatibility mode
• Install FreeMIDIby double-clicking on the Install FreeMIDI icon and following the on-screen instructions

• Install OMS by double-clicking on the Install OMS icon and following the on-screen instructions

• Connect your FreeMIDI or OMS compatible MIDI interface to the serial or USB port of your Mac

• Locate and open the OMS Setup program

• The Create a New Studio Setup dialog appears. Click OK.

• Click the checkboxes to select the port (modem and/or printer) to which your MIDI interface is connected. USB MIDI interfaces will be
detected regardless of these settings.

• Click Search. OMS will now search for MIDI interfaces connected to your computer.
A list of the MIDI interfaces connected to your computer will be displayed. If this list is correct, click OK. If MIDI interfaces that you have connected to your computer are not detected, refer to FreeMIDI’s troubleshooting information.

• OMS will now attempt to detect devices (keyboards, modules, samplers, etc.) that are connected to your MIDI interface. A list of devices or MIDI ports will appear. Click on the checkboxes next to each of the devices or ports that you wish to use. Click OK

• You will now be presented with a standard Mac OS Save dialog. Name your configuration, choose a convenient place on your hard drive and click Save

• Your studio configuration will now be displayed. Check that the on-screen MIDI connections are the same as your studio’s physical connections. Device information (manufacturer, model, name, properties, receive channel(s) and icon) can be edited by double clicking on the device / MIDI Interfaces icon. To connect devices, drag them to a MIDI interface, and click once on the in/out arrows

• When you have completed the setup, choose Save from the File menu

• Quit OMS Setup

• Locate and open the FreeMIDI Setup program

• You will be asked whether you wish to use OMS or FreeMIDI. Choose OMS. To change this later you will need to quit DP, locate and run the FreeMIDI Setup program, open FreeMIDI Preferences (File menu) and switch on Use OMS when available. Quit FreeMIDI and run DP.

• A dialog will appear informing you that FreeMIDI is in OMS compatibility mode. Click OK to continue. Your OMS Studio Setup will be displayed. Quit the FreeMIDI Setup program.

• Open Digital Performer

• Set up the Devices dialog as detailed in  MIDI devices.
18
some useful info here in this article about running both FreeMIDI + OMS
(At the same time, on the same machine)  8)

https://web.archive.org/web/20150606080830/http://www.soundonsound.com/sos/1996_articles/oct96/applenotesoct96.html

Quote
MARTIN RUSS investigates OMS and FreeMIDI compatibility, explains how you can protect yourself from copy protection, and rounds up more Mac news and useful 'net addresses...

 

While I was looking at Mark of the Unicorn's (MOTU) Digital Performer 1.7 for my SOS review (see the September issue) I used their FreeMIDI system to make the connection between the sequencer and my MIDI interface. This prompted me to look into what would happen if I had both MOTU's FreeMIDI and Opcode's OMS (Opcode MIDI System/Open Music System) in my system, so that I could use both programs -- or even if I didn't have OMS and wanted to use FreeMIDI. This is what happened...

FREE & EASY?

The FreeMIDI documentation explains that it and OMS can co-exist, and that you can use the OMS Emulator to run OMS applications with FreeMIDI. This all sounds reasonable; in fact, I had no problems installing FreeMIDI with my standard MIDI interface, and I felt at home quite quickly. The auto-configuration routine detected some of my eclectic collection of equipment (about the same amount as OMS, actually!) and provided almost exactly the same sort of visual mapping of my MIDI system. Apparently, the automatic detection of the equipment in your MIDI system is improved if you disable the transmission of MIDI clocks -- it makes all those test SysEx messages easier to decode.

But things became more complex when I tried the same thing with my Studio 5LX. The Studio 5 (and its smaller cousin, the Studio 4) is rather more than just a MIDI patchbay -- it functions as a sophisticated MIDI processing device too. In order to be used with FreeMIDI, it needs to be in 'MTP emulation mode', which also disables its MIDI processing, since it is now emulating a MOTU MIDI Time Piece (MTP), which is an 8-port MIDI Interface dedicated to providing patching and synchronisation facilities only.

In order to put the Studio 5 into emulation mode, you need OMS, since the Studio Setup application provides the only way to configure the emulation, and this application only works when OMS is running. There is an OMS Emulator system extension provided with FreeMIDI, but the Studio Setup application does not work with it. It is not possible to have Opcode's OMS in the Extensions folder inside the System folder at the same time as FreeMIDI's OMS Emulator -- OMS detects this and complains that there are two copies of OMS present. This is because the OMS Emulator replaces OMS, and so you need to disable the OMS extension.

I would normally try compatibility tests with the latest versions of software that I could obtain, but the current Vision version (3.0) requires OMS 2.0, and it does not recognise the OMS Emulator provided in FreeMIDI 1.2.4. In fact, version 1.2.4 of FreeMIDI does not recognise OMS 2.0 Studio Setup files either, which suggests that FreeMIDI is still working towards OMS 2.0 compatibility -- and it highlights the perils of using non-Opcode software with Opcode hardware! So I removed OMS 2.0, installed an old Vision 2.08 and OMS 1.2.3, and then restarted the Mac. I then used the Studio 5 Setup Application to put the Studio 5 into MTP emulation mode -- taking care to assign my MIDI devices to the ports (otherwise no MIDI input or output occurs -- and you can't change the emulation configuration without reloading OMS!). Inside Vision, this gave me a Studio 5 which appeared as normal, since when OMS is running, the Studio 5 still behaves like a Studio 5.

I then removed OMS from the Extensions folder, replaced it with the OMS Emulator, and restarted the Mac again. This time Vision saw what appeared to be a MIDI Time Piece, as expected. When it does not receive OMS messages, the Studio 5 goes into MTP emulation mode. Within MOTU's FreeStyle sequencer, the Studio 5 also behaved like an MTP, and so now I had replaced OMS with FreeMIDI (but I still needed OMS in order to achieve it!). The price of this was the loss of the MIDI processing in the Studio 5, and no way of patching things from port to port on the emulated MTP -- or was there?

I went to MOTU's web pages and got the latest version of the MTP Console, version 1.1, from:

http://www.motu.com/pages/DownloadMacConsoles.html

This is the application which allows the setup of a real MTP to be configured. Of course, expecting a Studio 5 which is emulating an MTP to respond in the same way is asking a lot, and it didn't work.

If you're not completely confused by this point, let's see what I've learned.
Firstly, FreeMIDI and OMS 2.0 compatibility seems to be flawed -- although this will no doubt be 'fixed in the next update' from MOTU. Secondly, you appear to need OMS in order to be able to not use it, if you want to use a Studio 5 (or 4). Thirdly, both MIDI systems seem to peacefully co-exist if you do not use the OMS Emulator -- and then you can change from one to the other as needed. I also discovered that this sort of investigation takes lots of time -- and I didn't even try using the inter-application communication, or any of the more sophisticated features of FreeMIDI or OMS. And finally, after all this fiddling about, I discovered that the Studio 5 patches no longer worked when I returned to OMS. Don't panic if this happens: you just need to use the 'Rebuild All' option to restore normal working.

HOW IT WORKS: COPY PROTECTION

Or rather, how to help it work. My recent transfer from one Mac to another required me to de-authorise lots of programs, and then re-authorise them on the new machine. Now you're probably expecting me to say that I maintain a detailed database of my installs and where the master disks are -- and consequently I can blithely say that everything went smoothly.

Not quite. Isn't over-confidence wonderful! For my major bits of music software, I keep the disks separate from all my working files and backups. So it was relatively easy to find the disks and do the de-authorise/re-authorise process. But there are several shareware utilities I use which were not quite so well organised. It took quite some time to find the postcard that told me the password for one program, and the sheet of paper containing the vital instructions only turned up when I was preparing my accounts for the taxman -- it was stapled to the receipt for the Eurocheque which I used to pay the software registration fee!

In the course of sorting out my hard disks before I transferred things from the remains of the old machine to the replacement, I took a detailed low-level look at the contents, and found quite a few hidden files on the boot drive, with names which indicated that they were the keys for the authorised programs. Some of these were in the System folder, others were in the root (highest or top) directory of the drive where the application was stored, and yet others were in the folder with the application itself. With any software copy-protection scheme, these files usually contain some sort of record about where and when they were placed on the disk, so you should leave them well alone -- which means that any sort of disk optimisation or defragmenting might upset them. And any attempt to move a folder around between drives may also cause problems. The trouble is that speeding up your hard drive, or moving a folder from a dying computer to a new one, is not the sort of thing that makes you think about de-authorising and then re-authorising later.

So here's the Apple Notes quick guide to maintaining your sanity about copy protection.

1. Keep your master or key disks in a place where you can find them easily and quickly.

2. Keep any passwords, registration or de-crippling documentation in a safe place, preferably with the master or key disks.

3. Keep a list of everything that requires anything other than a simple install from disks -- ie. anything that is protected. Stick this list to your computer monitor.

4. Get into the habit of pausing before you rush ahead with major changes to your computer hardware, especially disk drive upgrades (I changed my boot drive from a 40Mb to a 540Mb, and then discovered that I needed to put the 40Mb back, de-authorise, and then re-install the 540Mb and re-authorise to that!), or optimisation and defragmenting. That pause is where you remember that you have loads of de-authorising to do -- and you reach for that list!

 
19
All these script languages such as Ruby, Python Lua etc was not popular and in some cases not existing by the time classic Mac OS was prime time. Perl was probably the biggest script language at the time and there was a mac version of it.
But in general I think it's not worth bothering with script languages on OS 9 or earlier, even if you find an old build of some language its most likely extremely dated and if you intend to port something yourself, be prepared to encounter about every technical problem you can imagine. Mac OS 9 was by modern standards really messed up at the core.

Stick with the established languages at the time if you intend to get something done.
Yes, you're right, but there is a reason I brought these up, although I think I wasn't clear about it until now: I wanted to highlight all sorts of development paths, because I know some people out there other than myself will also be seeing this, and some of them are more likely to get their feet wet with general PowerPC (or even 68k) Mac development through one specific language or toolchain than another, provided they have a motive like I do. Some friends I have, for instance, are familiar with these, so the more I get uncovered, the better. I also am not strictly interested in only pre-OS-X development, although it is true Mac OS 9.2.2 is my biggest interest, so I find scripting languages that got popular only past the time of OS 9's prime are still important. I don't intend to port any of them myself, either, though. (Except maybe IBM's Node.js, but that is not a priority right now.)

Indeed, as for myself, for the sake of "getting things done", I'm actually already set on C, C++ and PPC assembly, using probably CodeWarrior Pro 9, Xcode 3.1.4, MPW and/or Fantasm/LIDE (Fantasm being an interesting program I saw you mentioning on another thread. I'll make a more detailed post on that later when I can), whichever I find suits best my needs. But I think I haven't looked at every nook and cranny yet, so I'm still after as much info on tools & everything else as possible. For my and others' sakes.


Speaking of which, those paragraphs on the kernel and those two link recommendations are being all of great help. I heard much about some of these kernel details from the good folk of this forum in other threads, and from random places online, but much of it I was completely unaware about. Thanks!
20
Hacking the System, Mac OS 9.3, and Beyond ! / Re: 9.2.3
« Last post by trevor12 on November 20, 2017, 06:39:22 AM »
I cannot mount os923.img in mac os 9.2.2. Any help ?
Pages: 1 [2] 3 4 ... 10