@kas1e

Thank You

There aer quite a few GUI classes that are opened in oca.c but not declared in oca.h

I missed that.

Mine has been fixed, I can send it to you or you can fix it up from there.
Once oca.h is corrected, just include it in any source file needing gadget classes declared.


Thanks for that.
Actually I'm kinda surprised that the only problem was an omissioon in a header file. There was a LOT of fast editing going on, something was sure to get missed.

updated oca.h is below.

[edit] Button, Scroller, and Slider gadgets are all in the public release
SDK53.30 .. hopefully updating the oca.h file and including it as needed
will fix the problem.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// oca.h
#ifndef OCA_H
#define OCA_H

#include <proto/intuition.h>

#define MAJ_REV 53

// Libraries
extern struct AslIFace *IAsl;
extern struct DiskfontIFace *IDiskfont;
extern struct GraphicsIFace *IGraphics;
extern struct IconIFace *IIcon;
extern struct IntuitionIFace *IIntuition;
extern struct LocaleIFace *ILocale;
extern struct UtilityIFace *IUtility;
extern struct WorkbenchIFace *IWorkbench;

// Gadget Classes
extern struct ClassLibrary *BitmapBase;
extern Class *BitmapClass;

extern struct ClassLibrary *ButtonBase;
extern Class *ButtonClass;

extern struct ClassLibrary *CheckBoxBase;
extern Class *CheckBoxClass;
extern struct CheckBoxIFace *ICheckBox;

extern struct ClassLibrary *ChooserBase;
extern Class *ChooserClass;
extern struct ChooserIFace *IChooser;

extern struct ClassLibrary *ClickTabBase;
extern Class *ClickTabClass;
extern struct ClickTabIFace *IClickTab;

extern struct ClassLibrary *GetFileBase;
extern Class *GetFileClass;
extern struct GetFileIFace *IGetFile;

extern struct ClassLibrary *GetScreenModeBase;
extern Class *GetScreenModeClass;
extern struct GetScreenModeIFace *IGetScreenMode;

extern struct ClassLibrary *IntegerBase;
extern Class *IntegerClass;
extern struct IntegerIFace *IInteger;

extern struct ClassLibrary *LabelBase;
extern Class *LabelClass;

extern struct ClassLibrary *LayoutBase;
extern Class *LayoutClass;
extern struct LayoutIFace *ILayout;

extern struct ClassLibrary *ListBrowserBase;
extern Class *ListBrowserClass;
extern struct ListBrowserIFace *IListBrowser;

extern struct ClassLibrary *RadioButtonBase;
extern Class *RadioButtonClass;
extern struct RadioButtonIFace *IRadioButton;

extern struct ClassLibrary *ScrollerBase;
extern Class *ScrollerClass;
extern struct ScrollerIFace *IScroller;

extern struct ClassLibrary *SliderBase;
extern Class *SliderClass;
extern struct SliderIFace *ISlider;

extern struct ClassLibrary *SpaceBase;
extern Class *SpaceClass;

extern struct ClassLibrary *StringBase;
extern Class *StringClass;
extern struct StringIFace *IString;

extern struct ClassLibrary *WindowBase;
extern Class *WindowClass;
extern struct WindowIFace *IWindow;


//
// Opens all libraries, classes, devices
// reads all args and tooltypes
// returns RETURN_OK, else RETURN_FAIL
//
int32 openAll(int argc, char **argv);

// always safe to call, handles any intermediate states
// displays any given reason by errMessage()
// ALWAYS returns RETURN_FAIL
int32 closeAll(CONST_STRPTR reason);

// use any available output, or create one if needed
void errMessage(CONST_STRPTR reason);

// easy OpenLibrary & GetInterface in one
// no need to store LibraryBase, as long as closeInterface is used to cleanup
// displays error details by errMessage if needed
APTR openInterface (CONST_STRPTR lib_name, int32 lib_vers,
CONST_STRPTR int_name, int32 int_vers);
void closeInterface (APTR interface);

// IIntuition->OpenClass() with error text output
APTR openClass(CONST_STRPTR className, uint32 classVers, Class **classPtr);

#endif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HornyOS4Ver1.4_Source.readme:

This is the first edit of HornyOS4 since the release of source code.

So far, I have:
removed key requirement
fixed an unfreed signal
expanded CAMD cluster selection
Changed variable types to int/uint
removed #ifdef OS4 conditions
added library pointers
removed #libauto from makefile
added warnings to makefile
replaced deprecated functions
bumped version to 1.4
added a *.debug build to makefile

And likely more I have forgotten.

There is more to be done, but this is a good point to get it back into GIT.
I have not yet run the program much more than loading an SMF and playing it. But that seems to work well enough.


BIG thanks to Timo Kloss for releasing the code.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kas1e:
If you are willing to put these back into the GIT, please email lylehaze @gmail.com so I can reply with the source.

Thank You
LyleHaze

@trixie

There is no way to tell.

clusters are between programs.
they do more than just inputs and outputs.

example:
I have an audio mixer (hardware) in my studio. I control it from a bcr2000, and from a software mix window. and I have a master volume slider beside my keyboard.

a script on startup checks for which devices are connected, and each is connected to cluster "mix" as input AND output.

when I turn a physical knob on the bcr2000, the master volume changes in the mixer. the software mix window master slider also moves. the vmeter volume slider LEDs also move to reflect the change. everything stays in sync.

later I run a script that reconfigures all mixer channels. All the devices update in real time.

later I'm recording a tricky bit, and I want to automate it all. I record "mix" and it's all captured into a track of horny. later when I play it back, the mixer and all the controls come alive with the controls.

so, is cluster "mix" an input or an output? there's many sources and many listeners connected there.

at work.. I'll check in later

Lylehaze

@trixie

ClusterList.lha has been uploaded to OS4Depot.
I think it's in Drv:Misc/ like most of the CAMD stuff.

Source included, it's really quite simple.

LyleHaze

kas1e:
As soon as I have a working build I will either return it to GitHub or give it to someone to do that for me.

Right now I'm adding code for Library/Interface/Class opening and closing.

Then I'll track down the missing signal.

After that I'll "check it in" one way or another. There ARE more bugs, many are GUI related, and I suspect it's from the use of macros.
Removing them would be a BIG job.. likely more than I am willing to try.

Let's see how much I can get done tonight before I pass out.
Getting old is no fun at all. :)

Lyle

[edit].. Mad typing again tonight. LOVE the CherryMX Brown keyboard. :)
HornyOS4 now opens it's own libs and classes.
-lauto and -lraauto have been removed from the makefile.

It SEEMS to still open, though I have not done much with it yet.

Time to sleep, tomorrow I'll hunt down the hanging signal.

Lyle

[edit2]
Add at the end of
void EntferneCamd(void) {
(near Midi.c line 220)

if(-1 != playsig)
{
IExec->FreeSignal(playsig);
playsig = -1;
}

NOW maybe I can get some sleep.

[edit 3]
Compiles clean against -Wall

@mr2

Sorry I'm late, I had some trobule logging in.

"Classic" MIDI ports (5 pin DIN) are serial at 31250 baud.
USB Midi ports are MUCH FASTER. so if all others things are equal, take the USB port.

Most devices with both will let you use the MIDI ports as an interface if you're connected by USB, so you get a couple classic ports for free.

camd.library is now part of a normal OS4 install.
camdmidi.usbfd is now part of a normal OS4 install.

There are a set of tools (mostly CLI) on OS4Depot called "camdtools".
From there you can find a command line program called "showclusters" that will list all MIDI clusters. if you plug in a compatible device, it will show up in that list.

I have a newer version that re-prints all cluster names on every change. So that is convenient. I don't think I've uploaded it anywhere yet.
Ask if you want it, very short simple program.

SoftSyn was a good effort, but I gave it up. "Timi" does a MUCH better job. It is a contribution, so you can find it on your OS4 install disks.

A good "simple" MIDI player is CAMDPlay, also from OS4Depot.
It LOOKS simple, but it took along time to get it just right.

I will answer questions as time allows, especially now that I can login here again (Thanks George!)


LyleHaze

@kas1e

If I make any real progress, I'll gladly put it back.
So far, I'm really just playing around.

Some of the stuff I'm doing may not be too popular:
I really prefer to use Interface pointers, and I've been adding them to the code. This may not be a popular choice.

I may also change variable types from BYTE WORD LONG to int8 int16, int32, again to be more aligned with the current OS4 standard.


I'm not sure if these will be wanted.. I pretty much just play by myself some times.

Very soon I'll hunt down the unfreed signal. Unless someone else get it first.

There's also a warning about the wrong Application interface index, but I only get that when I ran from workbench. (easily fixed)

The CAMD code sorted ports by "in" and "out". This is a common mistake. I removed this filter, and also raised the max number of ports fropm 16 to 24. Still not enough, I'll either raise it again or _properly_ set it for unlimited ports. Yes, I ahve a LOT of CAMD ports here, and more coming soon. Also SHOULD be able to create new CAMD ports by name. I'm not sure the current setup allows that.

Sorry about the late reply. I had a bit of trouble logging in here. George has kindly fixed it for me.

I'm open for suggestions, and if _some_ oif my changes are not wanted I'll gladly provide smaller updates with just the stuff that is wanted.

LyleHaze

As I type this on my X1000, I can hear fans laboring to maintain speed.
Even though the X1000 is a "fairly new" computer.. it's getting close to ten years old now.. (I think.?)

So there's a few things we must do that are not normal for the disposable generation:

My clock battery has probably only been changed twice. Most likely because I usually keep the X1000 powered up 24/7, so load on the battery is as close to zero as we will find.

The fan on the CPU cooler has already been changed once. While the replacement was good quality, it was not an exact fit. despite cleaning it recently it IS making a bit more noise than I am happy with. Tomorrow a much quieter (Noctua) replacement will arrive.
Do these PA6T's really need a fan on the heatsink at all? Since the processor is so "low powered", it seems a good option for passive cooling.. But no, I'm not willing to risk my X on testing. ;)

The "original equipment" HD4650 graphics card is still installed. I tried a newer high powered model once, but it just made too much noise and heat, so the same card my X shipped with has been running. I've been able to clean the fan enough to keep it going for ten years now, but it's finally just too worn out. Good news: I found an "exact replacement" fan, but it's coming on a slow boat from China. Delivery expected in about a month.

Rather than risk my HD4650, I'll be shutting off the X1000 when it's not in use for a couple weeks, until the replacement arrives. I am still convinced that keeping a computer on 24/7 is usually the best bet, since coming up to temperature and cooling repeatedly causes mechanical stress, not just between components and the board, but inside the chips as well.

It occurs to me that _most_ users of more common computers never even change the clock battery. The expected life cycle of a computer is so short nowadays.

So I guess replacing batteries and fans is just part of the cost of keeping computers alive forever... :)

If anyone else happens to need an "original" fan for a Gigabyte HD4650, I can pass along the vendor and part number I found.

If there is a proven reliable passive heatsink for the X1000, I'd love to know more about it.

And migrating to SSDs will remove another "moving part" prone to failure. I remember the old Seagate SCSI drives that needed a "thump" to get them spinning. Good Times.

I don't expect my X to live forever, but with a bit of care it might outlive me.
;)

Any program that renders to the screen will be blocked. Anything from fancy graphics to a simple printf() into a console window.
My MIDI player runs as two separate tasks. the actual player has no GUI, no window, no interface with Intuition at all. The "visual" part still locks on mouse buttons, but updates correctly as soon as it can.
I use MIDI messaging between the two to keep them in synch. It seemed the easiest way to go.

This topic needs a "like" button.

Thank You Gentlemen

@Spectre660

"The X1000 onboad audio is supported .Since 2013 apparently "


OMG.. Thank You Sir.

For a brief moment there I was afraid I had forgotten to send something in. It would be a terrible shame if I had the only X1000 with audio drivers for these past few years.

Remember to breathe... :)

I agree all around.
The Juli@ is a sweet card with great output stages.
I also agree that the X1000 is an expensive sound card.

Just to offer a sliver of argument, the X1000 supports optical audio out, which moves the "output stages" off the computer completely, without needing even a common ground, so that's nice.

But we are getting deep here. I doubt many would build enough audio gear around their Amiga to notice these details.

Or at least not many besides me. :)
Perhaps one day I'll show off some of the newer stuff. :)

@Helloworld

"Envy24HT is the only supported chip on OS4 that supports 24 bit depth with 19200hz sampling rate"

Except the builtin HDAudio on an X1000, of course.

non-handshaking (aka 3 wire) is _usually_ the best or only way to go with Amigas.

On classic systems, handshaking is optional, software controlled.
On the X1000, I think 3 wire is the only way.

But some (pc-related) systems can't seem to get down to 3 wire unless some jumpers are added, they seem to have the hardware handshaking permanently enabled. So until you've passed a test, I can only say "maybe".

MIDI over serial is 3 wire only as well, which some may know is where I spend most of my time.

Testing a null cable CAN be done with just one computer.. IF you can jump TX to RX at the other end of the cable. Then everything that goes out should come right back. Note: This test will NOT tell you if it's a straight or null cable, the test works the same on both cable types.

Also note: If your term software has "local echo" turned ON, you'll see two characters for every one you type. This is expected, not broken.

I have no direct experience with SAM serial, so you'll have to verify things for yourself.

Good Luck,
Lyle

Some days I think I should not be allowed on the internet.

I hope the damage is not permanent.

For others seeking information on NULL modem cables and Amigas, try this
http://wiki.amigaos.net/wiki/Advanced_Serial_Debugging_Guide

Roman wrote it, I had the first pass edits, many others have contributed as well.
RELIABLE terminal software is crucial, and I use one that is older than the hills, has a few warts, but it super reliable. it's called "Term"

details follow that link.

Yes, a paperclip is quite useful, as it can also clamp the probe tip. I keep a couple bent that way in my desk.

I also wrote Sentinel X-Logger, which allows Gen X Amigas to capture and save their own serial debug without a second computer.. but this is getting too far off topic.

Peace

@JosDuchIt

I try to give as complete an answer as possible.
Not just for you, but also for others who are reading this post who might also want to know how to do that.

I DID mention at the end of my post that you'll need a meter to figure out which wire goes to each pin.

After telling me that I did not answer your question, I see you went right on to do exactly what I suggested. Good for you.

Next time, I'll just keep to myself and let you figure it out.

@JosDuchIt

Much depends on what you'll use it for.
Our serial device supports 3 wire and 7 wire protocols.
There's also 5 wire, which is 7 wire with a few connections hardwired.

3 wire is transmit, receive, and ground.
To make a NULL cable connect ground to ground,
transmit to receive
receive to transmit.

This works for no handshaking, and XON XOFF handshaking.

The additional wires offer hardware handshaking, I'm sure you can look those up if needed.


Back to your question, if your mouse cables don't have the wires for hardware handshaking, you will be limited to 3 wire modes.

This picture is a MALE connector.
http://wiki.robotz.com/images/c/ce/Serialdb9pinouts.gif

You'll need a meter or something to figure out which wires connect to which pins. A small paperclip is handy for metering female connectors

@TSK

I designed a digitally controlled mixer that maintains the audio signal completely in the analog domain. "MidiBox Mixer"

No pots, no sliders, no static at all.

Small World. :)



I have considered making a proper "digital" mixer that works the same.
Xena would be far better suited for that one.

@mechanic

Yes, I still have an X1000. My Xorro is away at the moment though.


@Rob
I don't know enough about digital video to give a good answer.
_both_ incoming VIdeo signals would have to be wired to the Xorro card, as would the resulting output.
The two video inputs would have to be synchronized, just like the TBC's needed on toasters, for the same reason.

I just don't know.. interesting idea though.

@mechanic

The change from core to tile happened just before AmiWest 2012, I believe.
I did have copies of BOTH types of device file, so the one I posted may be either.

The only modification I remember was to add the clock information to the device file, so if the format has changed again try adding the clock information in a similar place..??

And if you modify an existing device file, you will want to rename it, so it doesn't later get confused with an unmodified file.
One benefit to beginng mine with "A-EON" is that we get promoted to the head of the alphabetised list.